UnusedWords

This page was copied from tw.o to here since ./languages/get_strings.php reffers this page in bonnie.

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}...{/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/{lang}/language.php.

a solution implemented in tiki1.9
sylvie: The strings must be added in the .php or .tpl into a special comment to be recognized by get_strings
//get_strings tra("the_string") in a php file
{*get_strings {tr}the_string{/tr} *} in a tpl file
Note there is no space before get_strings
So the developpers or the the translators who find such a string must add this kind of comments to have get_strings collecting automatically the string
See an example in tikilib.php
$action = "Removed"; //get_strings tra("Removed");

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.
";
echo "You should not have ended up here!
";
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 UserPagesylvie 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 generation 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 data structures / variable names should be defined.

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 correct functionality in that file.