ContentpluginApi FeatureRequest:TranslationService/LNGToken

[J.Bl]

Hello,

sometimes, in columns, provided by content plugins, values (usually texts) are shown, which are language specific (I do not mean the column names itself). Therefore, a nice to have feature of the content plugin interface would be, to have a thing like - let me say - a "translation service" in the interface. The file 'plugin_name.lng' in the Plugin directory is already used from the TC main program to translate the column names automatically, depending on the language settings in TC. Because the Plugin does not know nothing about this language settings (the token like ENG DEU FRA...) and translations, it can not make use of the file 'plugin_name.lng' by itself in an easy way whithout poking for additional language informations by itself.

So, additional Api functionality is requested: Either something to inform the Plugin about the language settings in TC, or this - so called - "translation service". Or, at best: both.

The language setting infomation can be a part of the ContentDefaultParamStruct (easiest way to implement, I think), or passed to plugin trough a new optional function, when the plugin is loaded for the first time. Then the Plugin can handle the language depending settings itself in an easy way.

And "translation service" goes like this: This optional "translation service" function is called by TC, when the plugin is loaded for the first time: The Interface requests the plugin with this function for a text, which the plugin wants to have to be translated. The interface translates the text and send the translation with the next call to the plugin, until the plugin answers with a blank text.

Regards

J.Bl

PS: I know, how to find out the language settings and translations independently by plugins and I use this things in my plugins. But the truth is, I do not like to poke for this informations in the wincmd.ini and elsewhere, if the TC can serve me this things easily on a salver.

[ghisler(Author)]

The official way to get the language is the following:
1. TC tells the plugin the location of wincmd.ini in the function ContentSetDefaultParams. The ini location given is the path to wincmd.ini plus a default ini name. Replace this name by wincmd.ini.
2. In wincmd.ini, look for the line LanguageIni=wcmd_xyz.lng

xyz is the language section TC looks for in your plugin's lng file.

[Clo]

2J.Bl
Hello!

¤ Just a detail to complement the good Author's explanation :
- When there are customized languages files, they must follow the rule enacted above for wcmd_xyz. lng as the basic name. Other specific characters must be placed forward the xyz string. That string must not be shortened.
- For instance :
Wcmd_eng2.lng
Wcmd_fra-p.lng
are valid and work for languages in the plugins, while
Wcmd_en2.lng
Wcmd_fr-p.lng
do not !
- I guess that might be indicated in the Readme of each plugin at the “Language” paragraph…

 Kind regards,
Claude
Clo

[J.Bl]

Hello,

The official way to get the language is the following:
1. TC tells the plugin the location of wincmd.ini in the function ContentSetDefaultParams. The ini location given is the path to wincmd.ini plus a default ini name. Replace this name by wincmd.ini.
2. In wincmd.ini, look for the line LanguageIni=wcmd_xyz.lng

xyz is the language section TC looks for in your plugin's lng file.

This is exactly what I do 'inofficialy' in my plugins, before I now read here, that this is the official way.

Is there a description of this process in an 'official' document (like a PluginDevHelpfile, PluginDevExample, PluginApiDoc, a previous posting in this forum, ...)?

If this posting here in this thread is the first official answer (ex cathedra), please put the description of this process in some of the PluginDevDocs.

Best regards

J.Bl

[Lefteous]

2ghisler(Author)

...Replace this name by wincmd.ini.

Yeah but this doesn't work in all cases. The user may use a file called "Whatever.ini". The routine to find out about the INI file name is much more complicated.

[J.Bl]

Hello,

2ghisler(Author)

...Replace this name by wincmd.ini.

Yeah but this doesn't work in all cases. The user may use a file called "Whatever.ini". The routine to find out about the INI file name is much more complicated.

Yeah ;-) you are right. I forgot to tell, that I think about this in the same way... at first...

But - mostly - a wincmd.ini exists in the same directory where the Whatever.ini resides. And the language setting is the same in both ini files - mostly. So - very often - christians description of the handling works without problems.

But, because this things work only 'mostly'... yeah ;-) you are right, "language setting infomation" is requested in the API in the described ways.

Regards

J.Bl

[ctiberg]

And what about yhr the user changing language while your plugin is already loaded? No amount of INI reading at startup will fix that Continually polling the INI isn't very efficient, either....