Is there a way to provide an overwrite, that is site-specific text, for any of the variables in a specific language file?
As I understand from documentation, the recommended way is to create my own language package by making a copy of another one. However, this seems an overkill if I just want to change the text displayed for 'loginusing' for example.
Your language pack only needs to include the strings you want to change.
If your language defines 'parentlanguage' in moodle.php, then you can define the language Moodle looks in for all the strings missing from yours (default is "en").
If your language defines 'parentlanguage' in moodle.php, then you can define the language Moodle looks in for all the strings missing from yours (default is "en").
Seems to me that these special (control) strings should not be mixed with normal translation strings but placed on top of the moodle.php or in a separate file -- not all translators appear aware of the special use of some strings, or forget in the fever of work, and translate them literally. Also, some languages have these strings in each of the language files whereas others only in moodle.php.
$string['thislanguage'] = 'es';
$string['parentlanguage'] = 'Muttersprache';
$string['parentlanguage'] = 'Bahasa utama';
$string['parentlanguage'] = 'Overordnet reservesprÂk';
$string['parentlanguage'] = 'rodiËovsk? jazyk';
$string['parentlanguage'] = '°ÄøÅ??';
$string['parentlanguage'] = '?ªÈ°ØÁ§?ËûË®Ä';
$string['parentlanguage'] = 'KNTJT: Jos kielellsi on kantakieli jota Moodlen pitisi kytt merkkijonon ollessa kateissa, tsmenn sit varten koodi thn. Jos jtt tmn alueen tyhjksi, kytetn englantia. Esimerkki: nl';
$string['parentlanguage'] = '?¯ø¿? : ??æ ¥Á??¿« æ?æÓ?° ???æ?æÓ?Û?È ±? ?´µÈ¿? ?Æ¿?ø?¿Ã ªÁ?Û¡?¿ª?ß ¥Á??¿« æ?æÓ ?¿ª ªÁøΫÿæ?«,±??Æ?Ì ±??Õ¿« ?µÂ?¶ ¡§¿««. ??æ ¥Á??¿Ã ¿Ã ?Û?¿ª ?µ?ÊøÏ øµæÓ?¶ ªÁøΫ.ø?:nl';
$string['thisdirection'] = 'diese Richtung';
$string['thisdirection'] = 'H¯jre mod venstre';
$string['thisdirection'] = 'L->P';
$string['thisdirection'] = 'ten kierunek';
$string['thisdirection'] = 'carta';
$string['thisdirection'] = '«?Ú Ô?Ó ÌÂÔÓÎÍË ';
$string['thisdirection'] = 'Èñ±ËÆÄÊñ?Âêë';
$string['thislanguage'] = 'es';
$string['parentlanguage'] = 'Muttersprache';
$string['parentlanguage'] = 'Bahasa utama';
$string['parentlanguage'] = 'Overordnet reservesprÂk';
$string['parentlanguage'] = 'rodiËovsk? jazyk';
$string['parentlanguage'] = '°ÄøÅ??';
$string['parentlanguage'] = '?ªÈ°ØÁ§?ËûË®Ä';
$string['parentlanguage'] = 'KNTJT: Jos kielellsi on kantakieli jota Moodlen pitisi kytt merkkijonon ollessa kateissa, tsmenn sit varten koodi thn. Jos jtt tmn alueen tyhjksi, kytetn englantia. Esimerkki: nl';
$string['parentlanguage'] = '?¯ø¿? : ??æ ¥Á??¿« æ?æÓ?° ???æ?æÓ?Û?È ±? ?´µÈ¿? ?Æ¿?ø?¿Ã ªÁ?Û¡?¿ª?ß ¥Á??¿« æ?æÓ ?¿ª ªÁøΫÿæ?«,±??Æ?Ì ±??Õ¿« ?µÂ?¶ ¡§¿««. ??æ ¥Á??¿Ã ¿Ã ?Û?¿ª ?µ?ÊøÏ øµæÓ?¶ ªÁøΫ.ø?:nl';
$string['thisdirection'] = 'diese Richtung';
$string['thisdirection'] = 'H¯jre mod venstre';
$string['thisdirection'] = 'L->P';
$string['thisdirection'] = 'ten kierunek';
$string['thisdirection'] = 'carta';
$string['thisdirection'] = '«?Ú Ô?Ó ÌÂÔÓÎÍË ';
$string['thisdirection'] = 'Èñ±ËÆÄÊñ?Âêë';
Thanks for finding those, these are all bugs in the packs that should be fixed.
A separate config.php is a good idea, too, will do that for 1.6
A separate config.php is a good idea, too, will do that for 1.6
Thanks for reporting - I'll fix them asap. (unbelievable this keeps working)
Fixed
While fixing, I found several hundreds of files, containing thischaracterset, thisdirection thislanguage and parentlanguage introduced by a bug inserted I guess in Moodle 1.2 and just recently fixed in 1.5. (-> all those strings were saved in every stringfile, while only moodle.php is used). I deleted them all.
They will not be reintroduced if translators use a recent 1.5 (files created early march were the last with the errors, so I guess the bug was solved that time).
While fixing, I found several hundreds of files, containing thischaracterset, thisdirection thislanguage and parentlanguage introduced by a bug inserted I guess in Moodle 1.2 and just recently fixed in 1.5. (-> all those strings were saved in every stringfile, while only moodle.php is used). I deleted them all.
They will not be reintroduced if translators use a recent 1.5 (files created early march were the last with the errors, so I guess the bug was solved that time).
Indeed. However, I feel that Moodle could go one little step further with supporting personalizing/localizing and extending language files. If I understand correctly, if I create a new language en_local to replace a few of the strings, then this language will show up as en_local in the language popup menu. Not look very professional and potentially confusing to some users. I'd like to use en_local but have 'English (en)' still in the menu instead of 'English (en_local)'. My users do not care whether I localized some texts or not.
Moodle could
offer additional special string, like thislanguageabbrevation, to be used as language abbreviation in the popup menu. Most often this would be the same as parentlanguage, I guess, so a variation would be to automatically use the parent language for the popup if one is defined.
or may be
designate the _local locale suffix as having a special meaning, designating a language customization, and automatically strip this suffix from the language code when building the popup menu (or use parentlanguage). This has a plus that makes such language folders easily identifiable as not part of the distribution.
I think this would also make it easier to add extra strings for a given site, particularly useful for multiligual sites (an alternative to multilang filter for fixed web elements).
Moodle could
offer additional special string, like thislanguageabbrevation, to be used as language abbreviation in the popup menu. Most often this would be the same as parentlanguage, I guess, so a variation would be to automatically use the parent language for the popup if one is defined.
or may be
designate the _local locale suffix as having a special meaning, designating a language customization, and automatically strip this suffix from the language code when building the popup menu (or use parentlanguage). This has a plus that makes such language folders easily identifiable as not part of the distribution.
I think this would also make it easier to add extra strings for a given site, particularly useful for multiligual sites (an alternative to multilang filter for fixed web elements).
For most sites this hasn't been an issue, because normally you choose the local language and remove all choice from users (so they never see the menu). These are settings the admin can make.
Something like the _local suffix is a good idea - can you file a feature request for it in the bug tracker so it's remembered?
Something like the _local suffix is a good idea - can you file a feature request for it in the bug tracker so it's remembered?
done
I thought about this issue some more and just added a comment to bug tracker.
Basically, I am thinking that it might be even simpler, for both users and developers, if the _local folders were not considered by Moodle as true language packs but extensions or whatever you want to call them.
Functionally, Moodle would check automatically whether such a _local file exists (I mean a file in _local folder for current language) and give it priority when resolving a string request.
I think this would localize the code changes to the function resolving the strings only. The only other place to deal with it would be web interface for editing language strings (but initially this could be even left out, requiring direct editing of files).
Basically, I am thinking that it might be even simpler, for both users and developers, if the _local folders were not considered by Moodle as true language packs but extensions or whatever you want to call them.
Functionally, Moodle would check automatically whether such a _local file exists (I mean a file in _local folder for current language) and give it priority when resolving a string request.
I think this would localize the code changes to the function resolving the strings only. The only other place to deal with it would be web interface for editing language strings (but initially this could be even left out, requiring direct editing of files).