• Feature request

Language Custom and all language files system holding - Proposal MOD ADD for Trunk 7x

Hi,

I was looking to tra.php and the way to hold the custom languages complements.

Note :
I note the recent change from array_merge($lang, $custom_lang) to $lang+$custom_lang which forbid custom to overload elements of system language using same English keys, the instruction which "merge" the two languages part into $lang staying into custom.php.

My proposal

To be clearer and for a best security and portability and capability of extensions. I propose (written ready to commit), which is described below, the details are :

FROM NOW :

System language file name(s)

System language has a file named "system_language.php" or "language.php" for backward compatibility (allowed multiple see above)

custom language files names "pattern"

Custom language has file named custom_language.php or custom.php for backward compatibility. (Others can be used see above)

Allow multiple files language with a pattern for names

Others file for language can be hold if their name is patterned <type>_language.php. <type> is allowed ref #a-z0-9_# compatible with php var names.

Names of arrays $lang

The "$lang" variables (arrays) defined by these files are of pattern "$lang_<type>"

Fusion of files

The concatenation (fusion) is now out of these files (custom) and become an element of the function "init_language" which must have this role, role which is then enhanced by the check of the contents and the real build of a $lang
A future option will allow when the routine are used to build or update new language files the "merge_array".

Role of init_language

So, the function "init_language" does the following :

1. check for language files (scandir) into language dir with valid patterns
2. tries to read (include) each file, if failed to include it is an held exception (for the moment just skip, later send system error with a comment) but not syntax error in language files which can crash)
3. checks the isset of arrays (corresponding to files names by pattern)
4. will checks the content (available chain key and chain values) php syntax validation on prefs
5. adds the arrays into $lang (fusion "+" not merge only on option)

the benefits

• This allows that tra (init_language) can check what is done and the content of $lang files and arrays generated.
• This allows to check at the $lang_* file definition load (check+include).
• This allows multiple files when need, particularly test phases.(split the files by nature of texts)
• This solves for the future the ability to introduce with backward compatibility "tikityped" strings to accept or not html tagged chains or others markup depending of the use of the strings (the typical sample is the strings of the name, descriptions, help, labels, warning, option in prefs definitions) but too the user fields content validation (can crash smarty and/or send a blank screen).
• May be it can be decided to associate a type of string depending of the syntax (the language array should have two value for each main key the string and the type).
• I have a separate proposal to define with backward compatibility the <type> of strings into the $lang arrays.

purpose

• This is done to make the languages files building and checking easier and have a better reliability in the phase of development of specific applications or when changes are necessary during exploitation.
• this allows to develop (I will) a function to run the same init routines with a request merge_files to generate an upgrade of file languages from more little files with changes todo.
• this allows lighter files and separate translated parts from the others etc.

What have been done

• I had just to add some lines (without specific checks for now) only managing the good load of a language file and their name pattern, no still enhancement in checking the contents of strings which needs typed strings.
• Tests
• no actually change to $tikidomains, can be enhanced

Ready to submit.
What's your opinion ? Do I commit ?

This bug has been demonstrated on show2.tiki.org

Please demonstrate your bug on show2.tiki.org

This bug has been demonstrated on show.tikiwiki.org

Please demonstrate your bug on show.tikiwiki.org