C5-8.2.1: What happens to translation if source file changes?
Permalink
Hello,
Say, I translated a package of version 1.2.3 - I've compiled a language .po file, translated all strings and compiled a binary .mo file. Strings in the .po file are shown tied to exact lines in .php files.
Then, the package is update to version 4.5.6. Some files are changed, say, 100 new lines are inserted, some old ones are deleted, some are edited - meaning the lines are now changed or even deleted.
Do I have to compile and translate the whole package from scratch again? How does translation work going between revisions?
Thank you.
Say, I translated a package of version 1.2.3 - I've compiled a language .po file, translated all strings and compiled a binary .mo file. Strings in the .po file are shown tied to exact lines in .php files.
Then, the package is update to version 4.5.6. Some files are changed, say, 100 new lines are inserted, some old ones are deleted, some are edited - meaning the lines are now changed or even deleted.
Do I have to compile and translate the whole package from scratch again? How does translation work going between revisions?
Thank you.
I follow this Howto:
https://documentation.concrete5.org/developers/concepts/localization...
i.e.
https://documentation.concrete5.org/developers/concepts/localization...
i.e.
concrete5 c5:package-translate community_store -l ru_RU concrete5 c5:package-translate community_store
If your .mo files are obsolete (that it, their contents is not synchronized with the PHP code), concrete5 won't be able to find the translations of the new strings added to PHP but that aren't in the .mo files.
So, you'll see these new strings in the source language (English).
The old strings that are in the .mo files will be translated though.
In order to refresh the .po file, adding the new translatable strings and removing the strings that are no more present in the PHP source code, you can run the c5:package-translate command again.
So, you'll see these new strings in the source language (English).
The old strings that are in the .mo files will be translated though.
In order to refresh the .po file, adding the new translatable strings and removing the strings that are no more present in the PHP source code, you can run the c5:package-translate command again.
So, does it mean that if, say, lines of code in php move or new lines added, the compiler will leave all old already translated strings and add only new ones to translate?
Does the .mo file only have English strings and their translations without reference to lines of code and php file names?
Does the .mo file only have English strings and their translations without reference to lines of code and php file names?
> So, does it mean that if, say, lines of code in php move or new lines added, the compiler will leave all old already translated strings and add only new ones to translate?
c5:package-translate will (1) add the new strings to be translated, (2) remove the old strings that are no more present in the PHP source code, and (3) keep the strings that are both in PHP and in .po files.
> Does the .mo file only have English strings and their translations without reference to lines of code and php file names?
.mo files does not contain any metadata (like references, comments, ...): all the lines in the .po file that start with # are lost during the conversion from .po to .mo.
So, when decompiling from .mo to .po (for instance with the msgunfmt command of gettext), you won't have that data.
c5:package-translate will (1) add the new strings to be translated, (2) remove the old strings that are no more present in the PHP source code, and (3) keep the strings that are both in PHP and in .po files.
> Does the .mo file only have English strings and their translations without reference to lines of code and php file names?
.mo files does not contain any metadata (like references, comments, ...): all the lines in the .po file that start with # are lost during the conversion from .po to .mo.
So, when decompiling from .mo to .po (for instance with the msgunfmt command of gettext), you won't have that data.
Aaaah, that's what happens!... ))
So I can grab any language file (e.g. download one from Transifex), translate what's not yet translated and that should work with any version of a package. Excellent.
Would you know why some strings don't get translated (some screenshots attached)? Is this a C5 bug, package bug or something else? If I change English in the php file, the text is shown as entered. So it's something to do with translation.
So I can grab any language file (e.g. download one from Transifex), translate what's not yet translated and that should work with any version of a package. Excellent.
Would you know why some strings don't get translated (some screenshots attached)? Is this a C5 bug, package bug or something else? If I change English in the php file, the text is shown as entered. So it's something to do with translation.
>Would you know why some strings don't get translated (some screenshots attached)?
In order to determine which strings need to be translated, concrete5 requires the use of the t() function. That is, in order to make a string translatable, instead of writing
you must have
Since the problematic strings are inside the package, you should ask the package developer to check if the PHP code is correctly written.
For the Community Store, you could create an issue athttps://github.com/concrete5-community-store/community_store... or write on Slack athttps://concrete5.slack.com/messages/C3N0FPMRU...
In order to determine which strings need to be translated, concrete5 requires the use of the t() function. That is, in order to make a string translatable, instead of writing
<button>Clear Chart</button>
you must have
<button><?= t('Clear Chart') ?></button>
Since the problematic strings are inside the package, you should ask the package developer to check if the PHP code is correctly written.
For the Community Store, you could create an issue athttps://github.com/concrete5-community-store/community_store... or write on Slack athttps://concrete5.slack.com/messages/C3N0FPMRU...
The code is fine, it's written properly.
Just as an example, community_store/blocks/community_utility_links/view.php Line 51:
Here's an extract of the messages.po:
The pictures have been attached to my previous message. As you can see, the string "Checkout" is not translated.
I have no clue why.
Just as an example, community_store/blocks/community_utility_links/view.php Line 51:
<a href="<?= \URL::to('/checkout') ?>" class="store-cart-link"><?= t("Checkout") ?></a>
Here's an extract of the messages.po:
#: packages/community_store/elements/cart_modal.php:206 #: packages/community_store/blocks/community_utility_links/view.php:51 #: packages/community_store/single_pages/cart.php:224 #: packages/community_store/single_pages/checkout.php:9 msgid "Checkout" msgstr "Оформление заказа"
The pictures have been attached to my previous message. As you can see, the string "Checkout" is not translated.
I have no clue why.
The PHP code seems ok.
Things to check:
1. your .po file has the string translated
2. you have compiled the .po file to the .mo format
3. the .mo file is placed under the directory /packages/package_handle/languages/locale_code/LC_MESSAGES/messages.mo (where package_handle is the handle of the package, and locale_code is the code of the language, like ru_RU for instance)
4. clear the concrete5 cache
Things to check:
1. your .po file has the string translated
2. you have compiled the .po file to the .mo format
3. the .mo file is placed under the directory /packages/package_handle/languages/locale_code/LC_MESSAGES/messages.mo (where package_handle is the handle of the package, and locale_code is the code of the language, like ru_RU for instance)
4. clear the concrete5 cache
1. The .po file is 100% translated.
2. The .po is compiled to the .mo
3. The .mo is placed in the right folder - the whole package is translated except for those few strings
4. Cache turned off and cleared 100 times. The package uninstalled and reinstalled 100 times - no difference
2. The .po is compiled to the .mo
3. The .mo is placed in the right folder - the whole package is translated except for those few strings
4. Cache turned off and cleared 100 times. The package uninstalled and reinstalled 100 times - no difference
Try to delete your .mo file, empty the concrete5 cache, and reload the pages: do you see the texts in English? If not, then your .mo file is not loaded at all.
Another thing to check: concrete5 supports multiple language files for every language:
1. the concrete5 core strings (saved as /application/languages/<language_code>/LC_MESSAGES/messages.mo)
2. the package strings (saved as /packages/<package_handle>/languages/<language_code>/LC_MESSAGES/messages.mo)
3. the site-specific strings (saved as /application/languages/site/<language_code>.mo)
Strings that are in 3. take the precedence, then 2. and finally 1.
Since your package translations (2.) have a less precedence than strings in 3., you could try to see if there's something wrong in the site-specific strings (you can temporarily empty the folder /application/languages/site and clear the concrete5 cache).
Another thing to check: concrete5 supports multiple language files for every language:
1. the concrete5 core strings (saved as /application/languages/<language_code>/LC_MESSAGES/messages.mo)
2. the package strings (saved as /packages/<package_handle>/languages/<language_code>/LC_MESSAGES/messages.mo)
3. the site-specific strings (saved as /application/languages/site/<language_code>.mo)
Strings that are in 3. take the precedence, then 2. and finally 1.
Since your package translations (2.) have a less precedence than strings in 3., you could try to see if there's something wrong in the site-specific strings (you can temporarily empty the folder /application/languages/site and clear the concrete5 cache).
I only have a core .mo file in the ru_RU folder, I don't have core .po or .pot files.
The 'site' folder is empty.
So I deleted the .mo file, cleared cache, refreshed pages - no change, some strings are in Russian, some are in English.
What's the CLI to make a Concrete core .po file? The internationalization instruction is only for packages.
Just as a guess, because that hints at something - there are 2 strings defined in the community_utility_links/view.php file:
and right underneath it:
See, the first one is set in the controller, and the second is defined in the view.php? So, the first one DOES get translated, but the second one does NOT! Any idea why? Does the language compiler only pick up strings in controllers and not view files?
The 'site' folder is empty.
So I deleted the .mo file, cleared cache, refreshed pages - no change, some strings are in Russian, some are in English.
What's the CLI to make a Concrete core .po file? The internationalization instruction is only for packages.
Just as a guess, because that hints at something - there are 2 strings defined in the community_utility_links/view.php file:
<a href="<?= \URL::to('/cart') ?>" class="store-cart-link"><?= $cartLabel ?></a>
and right underneath it:
<a href="<?= \URL::to('/checkout') ?>" class="store-cart-link"><?= t("Checkout") ?></a>
See, the first one is set in the controller, and the second is defined in the view.php? So, the first one DOES get translated, but the second one does NOT! Any idea why? Does the language compiler only pick up strings in controllers and not view files?
Yeah, that's right! I've added this to db.xml:
added this to form.php:
and changed this in view.php:
and it works!!!
So, it looks like it's definitely something to do with the compiler and strings in view.php.
Now the question is why?
<field name="checkoutLabel" type="string" size="255"></field>
added this to form.php:
<div class="form-group">
<?= $form->label('checkoutLabel', t('Checkout Label'));?>
<?= $form->text('checkoutLabel', $checkoutLabel ? $checkoutLabel : t("Checkout"));?>
</div>and changed this in view.php:
<a href="<?= \URL::to('/checkout') ?>" class="store-cart-link"><?= $checkoutLabel ?></a>
and it works!!!
So, it looks like it's definitely something to do with the compiler and strings in view.php.
Now the question is why?
How do you create the .po file? Is your package included in the concrete5 marketplace?