5.2.3.0 step_03.php doesn't seem to compile locales

nnhubbard · 2015-08-20 16:48:10 UTC

I built a new asset and installed it on our system. We are on 5.2.3.0, so I need to run step_03 to compile locales. But, for some reason it seems to never run. All of the strings of the asset are never translated.

Using the compile_locales.php script on an older system works correctly for this new asset.

Looking in step_03.php I do see a comment about Compile Locales, but it just says:

// Compile locales.
build_js_string_files();

Looking at the build_js_string_files function, I don't think it has anything to do with compiling locales.

Any idea why this would be?

Bart · 2015-08-20 22:03:41 UTC

I think it might be due to the new way strings are handled now in matrix for the new localisation support in admin.

I probably should have posted these changes on the forums back when 5.2 was released, so I apologise for the confusion and inconvenience. Localisation

In Matrix 5.2, we have done significant changes to the way that the strings and text is presented onto the screens in the admin interface. This was all done as part of idea https://squizmap.squiz.net/matrix/5333.

The new translation method uses .po files rather than XML files to source the content from. This means that all functions that called the XML files for text strings, have had to be changed to new functions that work with .po files instead. This has already been done in all Matrix core code base and all its associated packages. Custom Client Packages

This localisation change in Matrix means that custom packages that have been created will need to get updated to use the new string replacement function. The change itself is trivial and is very easy to do. However it means that anyone that is using a custom package on their install, will need to have their package and custom code updated when upgrading to Matrix 5.2. How To Update

First of all, you will need to move display names and notes from lang_screen_*.xml files back into their originaledit_interface_screen_*.xml files.

Then you will need to change any translate functions used. The following are examples of Matrix 5.1 string translate functions, and their 5.2 equivalents.

Translation without replacements:

- translate('code_for_string');+ translate('English string');

Translation with replacements:

- translate('code_for_string',arg1, arg2);
+ sprintf(translate('English string with arguments %1$s %2$s'), arg1, arg2);

Errors - no replacements:

- trigger_localised_error('PKG0001', E_USER_WARNING);
+ trigger_localised_error('PKG0001', translate('Unable to foo - can't bar'), E_USER_WARNING);

Errors - with replacements:

- trigger_localised_error('PKG0002', E_USER_WARNING, arg1, arg2);
+ trigger_localised_error('PKG0002', sprintf(translate('Unable to foo %1$s - can't bar %2$s'), arg1, arg2), E_USER_WARNING);

nnhubbard · 2015-08-20 23:00:44 UTC

So, basically the translate() function should use the real strings instead of a code?

nnhubbard · 2015-08-20 23:39:56 UTC

Got it working.

However, encoded HTML seems to print out the actual tags on the front end, rather than as HTML:

translate('The name of the sound to be played when the notification is recieved. Use the word &lt;strong&gt;default&lt;/strong&gt; for the default message sound. You can specify a custom sound that iOS plays when it presents the remote notification for an application. The sound files must be in the main bundle of the client application. &lt;em&gt;(iOS only)&lt;/em&gt;')

The end part of that is coming out as:

<em>(iOS only)</em>

Edison_Wang · 2015-09-10 23:20:58 UTC

This is expected behavior.

translate() won't change anything in the original text, so for example, < will still be < when you print it out in the html.

Then browser will simply treat it as a literal < symbol, rather than a html tag.

So If you need to use html tag, just use it straight away, e.g translate('<em>(iOS only)</em>');

The reason we have to use html entity in the translation text prior to 5.2 is because old translation system uses XML file to store translation text, and simply those html tags will break the xml format. So we have to use html entity in it, and later matrix will convert those entity back to original html tag.

This isn't needed anymore now.