The files with the suffix ~n~ (~1~, ~2~, ~3~...) are backups - safe to delete.
They are explicitly created, so I guess we should turn that off - or make it an option.
We might also use a .gitignore file here like *.~*.

The *.pot files (the template files) are getting updated with every run. This is a bit annoying and I believe it is also optional.

The *.po files (the actual language files) get updated when you update the templates and run make langfiles.

I think we should only update the pot files using make langtemplates, push them to Transifex, and retrieve the po files containing the translations.

I guess I should get to work on my Transifex library again now...

@elkuku could you please explain one more time what is the procedure after adding new language strings? I should only run make langfiles and then update necessary languages?

Sure, no problem at all - as it is by no means a "standard procedure" let me try...

After you changed the code in your PHP or Twig files you should run

• tracker.php make langtemplates
  This will create/update the pot language templates.
  Those may be handed over to the translators / Transifex.

If you want to translate yourself you do a

• tracker.php make langfiles
  This will create/update the po language files according to the templates created in the previous step.

After changing the po files you have to clean the cache to "see" the translations on the site. This can be done by simply deleting the /cache/g11n directory or, if you are logged in with an admin account, using the "clean cache" command from the "System" menu.

Hope that helps
@todo update docu....

And how to make myself an admin? I should write user_id in the config.json?

Your username would go in there.

    "acl": {
        "admin_users": [
            "mbabker", "elkuku", "b2z"
        ]
    },

And now all of us are admins :-D

Ah, I thought it should be ID :)

I've got to be doing something wrong. Ran make langtemplates and make langfiles, cleared cache, still not getting the right output.

And nevermind, that's me not realizing that lang debug is enabled -.-

I noticed interesting thing about the translation - using translate and _ produces same language string for a template file, but does not aggregate these keys. For example "Easy Test"|_ in the issue.index.twig and translate('Easy Test') in the issue.edit.twig will make the following in the Tracker.pot:

#: /templates/tracker/issue.edit.twig:111
msgid "Easy Test"
msgstr ""

#: /templates/tracker/issue.index.twig:77
msgid "Easy Test"
msgstr ""

But if the same method is used, then it will make the following:

#: /templates/tracker/issue.edit.twig:111
#: /templates/tracker/issue.index.twig:77
msgid "Easy Test"
msgstr ""

I think we should stick to one of these methods and completely remove the other one. I'am voting for _.

Hmm it shouldn't - they should both resolve to the same function.. :(
But I would also vote for _

@elkuku one more interesting thing I found. Here we are dynamically translating status_title. And it looks like make langtemplate can not find this string :( I guess we need to add this manually?

@mbabker we need your vote here ;)

Yes I noticed that also. I would suggest that we create a file that is never being included which contains only the strings that are present in database.

Agree. As I understand it will be some DbStrings.pot file and we should place it somewhere :) But where? Since all such translations belongs to the frontend we could place it under the templates dir?

I mean a php file - easier to handle ;)
Since they belong to the tracker App maybe
/src/App/Tracker/static_translations.php

<?php
g11n3t('my special string');

How does that sound ?

BTW what do you mean by "frontend" ?

BTW what do you mean by "frontend" ?

I meant "templates" or client side :) Well I am not against php file. Will you do it?

Will you do it?

oki

Actually I opted (again) for an automated thingy instead of manually maintaining stuff ;)

I have a general question - if I add/delete/update some language strings and then build a new language files do I need to push all of them or only those where changes were made?

And I would vote for this:

We might also use a .gitignore file here like .~.

or for this:

The files with the suffix ~n~ (~1~, ~2~, ~3~...) are backups - safe to delete.
They are explicitly created, so I guess we should turn that off - or make it an option.

I think this depends on how (and if) we'll handle translations via Transifex.

Generally I would say that the template files can be updated at any time (currently there seem to be differences in ordering between the systems - not sure)

If you make changes to the language files you should push them of course.

Those backup files - I think we'll turn them off completely.
I use a common .gitignore file across all my projects containing this pattern as it is a standard pattern for backup files.

Not sure whether this is the right place to post this but as you know, Transifex is under continuous development. One of the latest features that you will not see in individual projects, we have within OpenTranslators and knowing about this feature might help in you translation decisions:

Validation

"Set the validation checks to run on translated strings for each file format your organisation uses. Set, whether a translation should be rejected (“error”) or not (“warning”), if a check fails, or disable the check altogether. The translators will see an appropriate message, if an enabled check fails for a translation."

The default settings for a Joomla .ini file and the options are in this image:

We are able to do this for all the different file types that Transifex accepts.

Hils

What I mean is when I run makelangfiles it modifies all, not only those which I have updated. So I should push all, correct?

@b2z - Yes, push all. The last time I pushed the language templates, a lot of things changed unrelated to what I actually changed. In part it looked like because my system handles ordering things a little differently and in part because some stuff in the UI had changed and wasn't added to the templates.

Regarding Transifex, I went through my API Wrapper last night to validate what was already there still works and added a few more of the end points. Still a lot of structure work to do on that (finishing the API implementation, continuing to hack at my Joomla\Http fork to add in support for things that are lacking). I envision a workflow where if we were to use Transifex and my code, we have a simple CLI command to sync everything up and could potentially cron job it on the server so we're always serving the latest and greatest in terms of translations.

Translations is something we really should put some thought into now, as well as workflow on updating the base templates, since we are implementing the internationalized UI in the code.

Sure push them all, I don't think we'll get any conflicts ;)

@Hils Yes this is the right place - i guess ;)
That's interesting news about the validation, thanks for sharing.
Currently we have to set up a project first, think about the structure (last time I did that - mapping my language files to Transifex resources - it was a bit messy...) and then let the translators do their work and merge it all together - ideally before tagging 1.0 final ;)

/me agrees a lot with @mbabker on the automated workflow ;)

Since we have Transifex fetch in place now what will be the final procedure of committing lang changes?

Proposal

• Create a repository for translations - maybe joomla/jtracker-g11n ?
• Remove the language po files from the code repo, leaving the pot templates in place.

Periodically:

• Run make langtemplates and push the updated pot files to Transifex using update transifex
  OR use the feature provided by Transifex to "watch" the source files.

then

• Run get transifex to retrieve the language files.
• Run export langfiles to export them to a local repo clone.
• Push the changes to the backup repo.

Update a live server:

Now here is the tricky part... Being lazy (I like being lazy) we can just run get transifex on the server (if possible) and put online whatever comes from there.
Being paranoid you could argue that a malicious person could introduce some Vi*gra stuff that might reach our live instance on an automated update.

Having our backup repo we should be able to "review" the changes - if we have the required human resources available ;)

Some of the automated server stuff isn't quite working right still (don't know if git is working right in the cron job honestly) and I'm hitting memory issues with Composer. So, at least short term, a manual workflow is fine with me while I keep working on getting the automated part of it optimized.

So we should leave everything as it is, and update the po language files from Transifex to the main repo ?

For now, yes.

Sorry guys, I am a little bit confused. So:

1. Run make langtemplates and push the updated pot files to Transifex using update transifex
2. Run get transifex to retrieve the language files to local repo.
3. Push the changes to the main repo.

Is it correct?

Is it correct?

Yes I think that would be the work flow.

BTW: here is a Credits / Translators section auto generated from the language files.

Cool. But may be we should hide e-mails from the credits page? Potentially this could lead to spam :(

Best regards,
Dmitry

----- Reply message -----
From: "Nikolai Plath" notifications@github.com
To: "joomla/jissues" jissues@noreply.github.com
Subject: [jissues] Committing lang changes (#166)
Date: Fri, Jan 24, 2014 04:19
Is it correct?

Yes I think that would be the work flow.

BTW: here is a Credits / Translators section auto generated from the language files.

—
Reply to this email directly or view it on GitHub.

But may be we should hide e-mails from the credits page? Potentially this could lead to spam :(

Hu, I didn't get this either...
Note that the e-mail addresses are already "published" in our language files (e.g. here). Not as mailto links, but "scrapeable".
Is this really still an issue nowadays ? Sure spam exists but the harvesting methods have changed..

Dunno :) Need more opinions on it.

We need a voting thread ;)
CC: @HermanPeeren, Paulo Izidoro, @Hils

We should set up automated language file handling.

No arguments from me there, just gotta make sure the server supports it.

At this point you are the only one in our team who knows what the server supports ;)

Looks like it's there already. I ran a make langtemplates on the server and there doesn't look to be any issues. The Language line gets removed from the header, but that's the only difference that stands out (other than the strings get ordered differently). Check out http://issues.joomla.org/server-langtemplates.diff

Looks good. The removed (empty) language lines should be no problem, since we don't even process this information. Probably a version thing.

But, can you commit the changes to our repo? The Transifex update should be easier ;)

Done

AWESOME - we have a new collaborator ;)
Not sure how you can commit but not fetch?
Can we run this automated on a regular schedule?

It can't fetch on a cron job, works just fine when I'm SSH'd into the server.

Which probably means git commits won't work on a cron job either. May need to check with support on that to get it working.

Ya, this needs a support ticket, tried setting a cron job again and found this in the server logs:

------------------------------------------------------------
              Joomla! Tracker CLI Application
                         1.0.0-beta
------------------------------------------------------------
------------------------------------------------------------
                       Update Server
------------------------------------------------------------
sh: git: command not found


ERROR: sh: git: command not found

Call stack:
#0 JPATH_ROOT/cli/Application/Command/Update/Server.php(41): Application\Command\TrackerCommand->execCommand('cd /home/issues...')
#1 JPATH_ROOT/cli/Application/Application.php(249): Application\Command\Update\Server->execute()
#2 JPATH_ROOT/vendor/joomla/application/src/AbstractApplication.php(105): Application\Application->doExecute()
#3 JPATH_ROOT/cli/tracker.php(40): Joomla\Application\AbstractApplication->execute()
#4 {main}

Just tested everything. As long as the job doesn't include git commands to the shell interface, everything works just fine.

And the issue with git is that the executable isn't being found in the environment the cron runs with. It works if I hardcode the full path to the executable but that's not a great solution IMO. which git didn't find it on the cron job either.

If the full path works we should use it (we could add a config option here)
I'd be more concerned about user credentials, but if you have that covered - perfect

All the credentials we need are already in the config and I just generated SSH keys for that account today. I think we're good to go, just need to deal with that git issue. If we're going to keep pushing the translations into the repo, the update command will need some code to commit and push the changes. Then, we're fully automated.

Sounds good, I remember the SSH thing wasn't that easy ;)

If we're going to keep pushing the translations into the repo

I think we should remove them at some point - I'd love to see them in a separate repo, so we would need the code..

Then, we're fully automated.

hooray :)²

What is the current status of this? Is this process still valid?

Run make langtemplates and push the updated pot files to Transifex using update transifex
Run get transifex to retrieve the language files to local repo.
Push the changes to the main repo.

I see that jissues-bot doing some job for us. @elkuku @mbabker can you elaborate here cause I am a little bit lost :)

Unfortunately I am not invited to this playground, so @mbabker is the only one knowing what's going on there currently
Not sure if it really makes sense to set up a cron or if we (@mbabker) can manage to manually run this periodically.
I think we are 99% at closing this.

I trigger a shell script on the server every so often to manage the translations and it's honestly working out just fine I think.

So basically this is staying as is if want to do it manually?

Run make langtemplates and push the updated pot files to Transifex using update transifex
Run get transifex to retrieve the language files to local repo.
Push the changes to the main repo.

Yep. This is the shell script I'm using:

php cli/tracker.php make langtemplates
git commit -am "Update language templates"
php cli/tracker.php update transifex
php cli/tracker.php get transifex
git commit -am "Fetch updated language files"
php cli/tracker.php clear cache
git push

Nice. Then this should be documented and closed :)

That looks just fine. So let's close this.