Reply to thread

Message

<blockquote data-quote="Albert" data-source="post: 707588" data-attributes="member: 67886">AW: Globalization string management toolHey David, that looks pretty well!I would say, all your assumptions are correct. And I like the UI very much - to have a base form for the complete project and to have an own form per plugin.The only problem I currently see is this: if new localization resources for a new language should be added, the developer isn't forced to add those resources in the same plugin as the english language - in fact, a new language will most probably be provided in a separate plugin which covers the strings for one or multiple other plugins.Example 1:The default plugins Media, SkinBase, Weather, ... contain the default (english) language.A second language plugin for german will provide german resources for all those default plugins.Example 2:If a user has installed a plugin OnlineVideos (for example), there also exists a german localization plugin which covers the string resources for OnlineVideos (and maybe for more). That means, this user will probably have multiple plugins installed containing german language and all those plugins are different from the plugins where the base english resources are located.To make that manageable, I think we need another kind of dependency concept; the dependency of a language plugin (e.g. german for OnlineVideos) to the one (or more) &quot;parent&quot; plugin OnlineVideos where the default (english) language is contained. Only if the StringManagement tool knows that dependency, it can check all german strings against the default strings.</blockquote>

[QUOTE="Albert, post: 707588, member: 67886"] [b]AW: Globalization string management tool[/b] Hey David, that looks pretty well! I would say, all your assumptions are correct. And I like the UI very much - to have a base form for the complete project and to have an own form per plugin. The only problem I currently see is this: if new localization resources for a new language should be added, the developer isn't forced to add those resources in the same plugin as the english language - in fact, a new language will most probably be provided in a separate plugin which covers the strings for one or multiple other plugins. Example 1: The default plugins Media, SkinBase, Weather, ... contain the default (english) language. A second language plugin for german will provide german resources for all those default plugins. Example 2: If a user has installed a plugin OnlineVideos (for example), there also exists a german localization plugin which covers the string resources for OnlineVideos (and maybe for more). That means, this user will probably have multiple plugins installed containing german language and all those plugins are different from the plugins where the base english resources are located. To make that manageable, I think we need another kind of dependency concept; the dependency of a language plugin (e.g. german for OnlineVideos) to the one (or more) "parent" plugin OnlineVideos where the default (english) language is contained. Only if the StringManagement tool knows that dependency, it can check all german strings against the default strings. [/QUOTE]

Verification