Plugin localization

We want plugins to be translatable, using same functions as in core (eT, gT, ...).

= Questions = 1.   Did we want plugin allowed to replace string by core (or not ?)'
 * What do you mean by replace? If you write  in a plugin, I think it should first look in the plugin translation file, and if no string exists, check the core translation.  Olle (talk) 20:43, 17 July 2016 (CEST)
 * No it's more : if CORE string use gT("Male")/eT("Male") and user want to show "Boy" in all of his survey. In fact it's related to "Email template" feature request somewhere. If we add a plugin system to update core string, we don't need a plugin to allow updating "Default email templatre", it's can done easily. Or linked with https://bugs.limesurvey.org/view.php?id=10260 / DenisChenu (talk) 19:31, 17 July 2016 (CEST)
 * Ah, I see. Then we're talking about different things. My topic is about localizing the strings from a plugin, not changing the core strings using events. Olle (talk) 20:40, 17 July 2016 (CEST)
 * Its different OR the same thing : for example with beforeControllerAction : you can add action with a plugin OR replace completely LS core. In fact : here : https://github.com/LimeSurvey/LimeSurvey/pull/522/files#diff-a9dbc6157f3066d12e04af89a4bca062R4020 if we change the order of the array_merge : system is different using exactly same function. If we load Core translation and after Plugin translation : a plugin can replace core translation.

2. Do we want to use the same translation homepage for non-engineers as in core?
 * Think we don't need really to make a demo plugin. If we have a way to extend language : it can be done in a plugin after. The question is more : did we restrict the system to po/mo OR/AND to DB OR/AND PHP file or did we allow ANY class to be used (extend CMessageSource, can be (CGettextMessageSource|CDbMessageSource|CPhpMessageSource|OwnMessageSource|OwnAndBrokenMessageSource) / DenisChenu (talk) 19:31, 17 July 2016 (CEST)

= Some idea =


 * 1) If we can have multiple http://www.yiiframework.com/doc/api/1.1/CMessageSource  : i think solution can be here. Must test with different ClassName
 * 2) If we disallow updating core message : maybe http://www.yiiframework.com/doc/api/1.1/CMessageSource#onMissingTranslation-detail
 * 3) Exiting LS function : https://github.com/LimeSurvey/LimeSurvey/blob/master/application/core/LSYii_Application.php#L206
 * 4) Possible update with Yii  ?
 * 5) https://github.com/LimeSurvey/LimeSurvey/blob/master/framework/i18n/CMessageSource.php#L45 (using category ? )
 * 6) Can we extend it in https://github.com/LimeSurvey/LimeSurvey/blob/master/application/config/internal.php#L146 ?
 * 7) to be tested usage in config/internal : https://gist.github.com/Shnoulle/e3ca675fb7a8f23905881e61d699cce3 (already use this for cache : https://gist.github.com/Shnoulle/54773f2cdf3aeb90a0f87b798875542c) : see http://stackoverflow.com/a/12351509/2239406 too
 * 8) Usage with module/extensions : http://www.yiiframework.com/doc/guide/1.1/en/topics.i18n#c3902

= linked mantis : =


 * https://bugs.limesurvey.org/view.php?id=9649 : update core language
 * https://bugs.limesurvey.org/view.php?id=8289 : replacing "default email" template
 * https://bugs.limesurvey.org/view.php?id=10260 : privacy message
 * https://bugs.limesurvey.org/view.php?id=9650

= Suggestion =

Suggestion 1

 * 1) Translator first look for string in LS core translation. If not found, it will look in plugin specific translation.
 * 2) All plugin mo-files must be saved as   (by default)
 * 3) We will subclass CGettextMessageSource, CGettextMoFile, CGettextPoFile. This is necessary to not force plugin locale files to have context (msgctxt).

Suggestion 2 (plugin string translation)
This is done in maintenanceMode but i prefer a cleaner solution (if possible without $this->gT or other)
 * 1) Translator look at plugin translation if plugin dev want it
 * 2) If not found : search on LS transation (think not needed : plugin dev can already use default function for this)
 * 3) Default is   with CGettextMessageSource.
 * 4) config.json can use another messageSource (own function to allow user to update string himself)

Note: Yii slightly abuses the mo file format, where a "category" in Yii is a "context" in mo/po.

= Implementation =

Current Implementation (pre 3.0 alpha)
This commit: https://github.com/LimeSurvey/LimeSurvey/commit/2b2ac333dd867b7821e60c420ac45420f6eb9ddf

Plus some commits after.

Manual page: https://manual.limesurvey.org/Plugins#Localization

Cons with current implementation:
 * Registers a new component for each plugin
 * In which way is this a con? Olle (talk) 10:36, 16 February 2017 (CET)
 * Don't know : can remove this con (in fact : think we MSUT register a new componenet (excpet for core update string ?) DenisChenu (talk) 10:53, 16 February 2017 (CET)


 * Using /de/de.mo make difficult to load language only one time

Possible implementation

 * 1) Look if locale directory exist
 * 2) If yes : add the component for the plugin with default settings
 * 3) Default settings can be update by config.json
 * 4) Create the clean translation function

Other implementation

 * 1) Add new language string directly in messages
 * 2) Allow to replace gT(string) from core by a plugin

Just concept, no code