History: UnusedWords

Technical description
The get_strings.php script collects all strings that are enclosed by the tra function in .php files and all strings that are enclosed by ...{/tr} in .tpl files. The problem is that some tiki functions/features generates strings on the fly (reportedly this happens for flags and possibly in other places), which means that these strings can not be found and will not end up in .../tiki/lang//language.php.

Current and bad solution
Some translators have "solved" this by adding these strings in language.php. The problem with this aproach is that subsequent usage of get_strings.php will mark these strings as unused. This is a problem when get_strings.php is used on an old version of language.php but a new version of Tiki. In that case legitimately unused strings will be mixed with strings that some translators have added manually. These strings will also only be visible for translators of that language.

Suggested short and long term solutions
It is of course possible to extend get_strings.php to find out which the dynamically generated strings are (preferably through plugin modules - contact me for suggestions on plugin architecture either through commenting this article, or through UserPagedocekal ). This should be considered a long term solution.

In the mean time I suggest the following method to export dynamically generated strings to get_strings.php.

Make a .php file (either one global or one for each type of dynamically created strings) as the example below. The "error text" could be improved considerably.

<?php
echo "This file is only provided for translation support.<br />";
echo "You should not have ended up here!<br />";
echo "Press the back button in your browser.";
exit (0);

// Here comes the dynamiaclly generated strings for module xxx.
tra ('flagname1');
tra ('flagname2');
tra ('flagname3');
// etc.
?>

Adding such a file to a suitable place in the tiki file structure will achieve two ends:

1. The strings will no longer appeare in the untranslated words section
2. Other translators will be aware of that these strings should be translated to and they will not have to rely on trail and error to find out which strings should translated/added to language.php

Chealer9 comments : That looks like a good solution...could you mention a default file to do that.

docekal: My suggestion to this temporary solution is to do it like sylvie suggested. Put the strings in
the file where they are generated just enclose them in an if (false) e.g.:
if (false) {
tra ('flagname1');
tra ('flagname2');
tra ('flagname3');
}
sylvie: The important point is to keep the constant and the translation call close to each other. My favorite solution (that needs a simple change in get_strings) is to introduce a special comment that get_strings can collect. The false need sometimes to be put in a loop - not very pretty. Example /*get_strings: flagname1 */ just near the place you have the flagname1 constant.

My suggestion to this problem is that code that generates strings on the fly should be able to take a
parameter "get_strings" or perhapps have a function generate_strings and generate all the strings into
the "same" fileapath as the original file with the only difference that its root will be different (e.g. dynamic_strings)
The generatation of such files should be initiated by get_strings through a defined interface (e.g. support could
be provided to actually generate the files only the datastructures/variable names shoudlbe defiined.
Also the plugins needs to be registered. My suggestion is that this is done in an directory called get_strings_modules which contains files which include the corresponding .php-file and calls the corect functionaliity in that file.