User tests: Successful: Unsuccessful:
So, here's the first cut of being able to work with Transifex to manage translations.
I've added in my library which has enough of the Transifex API in place to use it here and a new CLI command, get transifex, which will fetch translations. Currently only the JTracker Core (/src/JTracker/g11n) is supported as that's all I've uploaded to my test project at https://www.transifex.com/projects/p/babdev-library-api-test-project/.
Added also are transifex options to the configuration JSON to authenticate and define the base project.
Still a lot to build out (like the rest of the get command, a push command, a project on Transifex, etc.), but it's enough of a teaser to get going :-)
Seems like good to merge? ;)
Far from ready to merge, I've barely gotten started ![]()
| Labels |
Added:
enhancement
language
|
||
I've populated Transifex now with all the .pot templates that it would take. The GitHub and System apps aren't uploaded because the templates are empty.
| Title |
|
||||||
Update script implemented and baseline docs complete. I think this is everything we'll need to have this working.
I just hacked together a put transifex command that also creates new resources providing an --init parameter.
/**
* Upload language templates.
*
* @throws \DomainException
* @return $this
*
* @since 1.0
*/
private function uploadTemplates()
{
$transifexProject = $this->getApplication()->get('transifex.project');
$init = $this->getApplication()->input->get('init');
defined('JDEBUG') || define('JDEBUG', 0);
ExtensionHelper::addDomainPath('Core', JPATH_ROOT . '/src');
ExtensionHelper::addDomainPath('Template', JPATH_ROOT . '/templates');
ExtensionHelper::addDomainPath('App', JPATH_ROOT . '/src/App');
$scopes = array(
'Core' => array(
'JTracker'
),
'Template' => array(
'JTracker'
),
'App' => Folder::folders(JPATH_ROOT . '/src/App')
);
foreach ($scopes as $domain => $extensions)
{
foreach ($extensions as $extension)
{
$name = $extension . ' ' . $domain;
$alias = OutputFilter::stringURLSafe($name);
$this->out('Processing: ' . $name . ' - ' . $alias);
$templatePath = Storage::getTemplatePath($extension, $domain);
if (false == file_exists($templatePath))
{
throw new \DomainException(sprintf('Language template for %s not found.', $name));
}
$this->out($templatePath);
try
{
if ($init)
{
$this->transifex->resources->createResource(
$transifexProject, $name, $alias, 'PO', array('file' => $templatePath)
);
$this->out('<ok>Resource created successfully</ok>');
}
else
{
$this->transifex->resources->updateResourceContent(
$transifexProject, $alias, $templatePath, 'file'
);
$this->out('<ok>Resource updated successfully</ok>');
}
}
catch (\Exception $e)
{
$this->out('<error>' . $e->getMessage() . '</error>');
}
$this->out();
}
}
return $this;
}
maybe you can combine this ;)
Mmm, I just deactivated a setting that seems to import translations from a translation database on importing the source language files.
I don't feel like this is a good option, so I'm going to re-upload them - I hope this is OK ;)
OK I re-uploaded the templates and uploaded the german translation files.
@b2z can you upload the russian files here: https://opentranslators.transifex.com/projects/p/jtracker/language/ru_RU/ in order to get the credits ?
BTW, the new Transifex translation UI look really cool ![]()
Did it except Debug App, because during upload it shows me that there is a syntax error... But I can't find it.
Sorry I forgot about that, I had similar problems too :( - Quick fix:
$ vagrant ssh
vagrant@debian-7:~$ msgfmt -c /vagrant/src/App/Debug/g11n/ru-RU/ru-RU.Debug.po
/vagrant/src/App/Debug/g11n/ru-RU/ru-RU.Debug.po:79: a format specification for argument 1 doesn't exist in 'msgstr[0]'
/vagrant/src/App/Debug/g11n/ru-RU/ru-RU.Debug.po:87: a format specification for argument 1 doesn't exist in 'msgstr[0]'
msgfmt: found 4 fatal errors
So I fixed this by doing:
#: /src/App/Debug/TrackerDebugger.php:379
#, php-format
msgid "One language file loaded"
msgid_plural "%d language files loaded"
msgstr[0] "Загружен один языковой файл (%d)"
msgstr[1] "Загружено %d языковых файлов"
msgstr[2] "%d"
I think what happens here is that gettext is checking that "php-format" strings (like sprintf and plural strings) have all the parameters present.
This: http://www.gnu.org/software/gettext/manual/html_node/Translating-plural-forms.html mentions at the very end a similar case of what we have here.
I think we should write a test routine to check language files and provide a somewhat better error message ![]()
@elkuku thanks fixed it. But I wonder will this (%d) affect the translation itself? Can't test it, cause does not have any single example like "One database query" :)
And the second question is - how we now are processing all translations? For example I changed something in .po file, should I push it to the project or to OT?
How I manage my extensions is I edit the main en-GB files and push to Transifex then pull down translations there. One mistake I probably make is having the translated .ini files in my repos. So I'd almost suggest that only the template .pot files be in the repo and the translations be added to .gitignore and only pulled down at the server or whomever is developing locally.
Makes sense.
Best regards,
Dmitry
----- Reply message -----
From: "Michael Babker" notifications@github.com
To: "joomla/jissues" jissues@noreply.github.com
Subject: [jissues] Add support for fetching from Transifex (#286)
Date: Sun, Jan 19, 2014 23:14
How I manage my extensions is I edit the main en-GB files and push to Transifex then pull down translations there. One mistake I probably make is having the translated .ini files in my repos. So I'd almost suggest that only the template .pot files be in the repo and the translations be added to .gitignore and only pulled down at the server or whomever is developing locally.
—
Reply to this email directly or view it on GitHub.
While I see the intention I don't fully agree.
If we don't want to "pollute" the main repo we should create a separate repository that only handles translation matters. Good translation files are the result of "hand work" from good people. I think we should definitely keep the "point of truth" in some master branch in a repository that's under our "control".
does not have any single example like "One database query" :)
The markdown test page uses currently a single database query
but you can do something like this:
{% for i in range(0, 25) %}
{{ i }}:
{{ g11n4t('One database query', '%d database queries', i)|format(i) }}
<br />
{% endfor %}
That gives me:
0: 0 FORM 2 запроса
1: 1 FORM 0 запросов
2: 2 FORM 1 запрос
3: 3 FORM 1 запрос
4: 4 FORM 1 запрос
5: 5 FORM 2 запроса
6: 6 FORM 2 запроса
7: 7 FORM 2 запроса
8: 8 FORM 2 запроса
9: 9 FORM 2 запроса
10: 10 FORM 2 запроса
11: 11 FORM 2 запроса
12: 12 FORM 2 запроса
13: 13 FORM 2 запроса
14: 14 FORM 2 запроса
15: 15 FORM 2 запроса
16: 16 FORM 2 запроса
17: 17 FORM 2 запроса
18: 18 FORM 2 запроса
19: 19 FORM 2 запроса
20: 20 FORM 2 запроса
21: 21 FORM 0 запросов
22: 22 FORM 1 запрос
23: 23 FORM 1 запрос
24: 24 FORM 1 запрос
25: 25 FORM 2 запроса
I believe this might help you in testing those strange pluralization beasts ;)
I think that you may choose to translate either online on Transifex (preferred) or local and then uploading the files to Transifex.
Thanks, will try and see :)
If we don't want to "pollute" the main repo we should create a separate repository that only handles translation matters.
But if we will add .po to .gitignore then we will not "pollute". Then the standard procedure would be
translate either online on Transifex (preferred) or local and then uploading the files to Transifex.
Isn't it?
Isn't it?
It is ;)
What I am trying to say is, that I would like to have a "hard copy" of the language files present in a(nother) repository.
And, well, the advantage of po files is, that you actually don't need any language file for the "default language" so, the pot files might also be transferred to another repository ![]()
And, well, the advantage of po files is, that you actually don't need any language file for the "default language" so, the pot files might also be transferred to another repository
Do not understand - how to update these .pot files then? It was easy with make langtemplates :) Or I miss something?
I made some adjustments.
New command: update transifex --create will initially create the resources.
Seems like the next language we are going to "speak" will be Portuguese. I just received a mail from the guy maintaining this interesting site: https://sites.google.com/site/transjoomla/home
Are we ready to merge this ?
Can't think of a reason not to merge it. Only thing to work out is handling push/pull with Transifex, but that's a minor detail compared to actually getting the code written.
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2014-01-21 04:42:37 |
So what is the final procedure dealing with the translations? Could be nice to have a docu ;)
Best regards,
Dmitry
----- Reply message -----
From: "Nikolai Plath" notifications@github.com
To: "joomla/jissues" jissues@noreply.github.com
Cc: "Dmitry Rekun" bzzjuka@gmail.com
Subject: [jissues] Add support for fetching from Transifex (#286)
Date: Tue, Jan 21, 2014 06:42
Merged #286.
—
Reply to this email directly or view it on GitHub.
Paulo who contacted elkuku already has access as he is one of our pt-PT co-ordinators and he has begun translating: https://opentranslators.transifex.com/projects/p/jtracker/language/pt_PT/ . Should we start promoting this project to our translators yet? It looks like you are ready :) This is our complete list of teams:
https://opentranslators.transifex.com/projects/p/opentranslators/
Awesome!
@testAfter adjusting the config.json with the project
babdev-library-api-test-project, and my credentials, I was able to fetch (and overwrite) the JTracker Core language files.I think it's time now to figure out the best way to set up our "resources" for the core, template and various Apps on Transifex. Maybe #OpenTranslators (@Hils) could guide us here?
Just in case, I already created a JTracker project - just to reserve the name
And last (but hopefully not the least) a teeny-tiny reminder about our Documentation:
I am convinced at this point that it is a good idea to add "some words" that you have in your mind while coding a new feature, and I declare hereby to do my best to actually put it in practice myself and to remind others when I feel it's appropriate.
"Smile"