Reply to thread

Message

<blockquote data-quote="Albert" data-source="post: 686993" data-attributes="member: 67886">AW: Globalization string management toolI absolutely understand your problem with those string instances which are composed at runtime. You're absolutely right, it is not computable which of those dynamic occurences are globalized strings. That's the reason why such a &quot;Find unused strings&quot; function potentially can never find all occurences. Always a user has to look over the result, and the tool must be built to make it possible for the user to check each single search result.The tool should be a help for devs who used localization resources as said in the guidelines (which are not written yet...). That means, in code we have localization string references like this:[CODE]&nbsp; &nbsp; public const string RES_PLAYLIST_LOAD_NO_PLAYLIST = &quot;[Media.PlaylistLoadNoPlaylistText]&quot;;&nbsp; &nbsp; ...&nbsp; &nbsp; dialogManager.ShowDialog(SkinBase.General.Consts.RES_SYSTEM_ERROR, Consts.RES_PLAYLIST_LOAD_NO_PLAYLIST, DialogType.OkDialog, false, null);[/CODE]That example is taken from the Media plugin.Another way to reference localized strings is to use those placeholders as literal constants in the code like[CODE]&nbsp; SomeMethod(&quot;[SomeSection.SomeString]&quot;);[/CODE]To scan both of those strings, you simply need to scan for &quot;[ at the beginning, n alpha-num chars, a dot, n alpha-num chars and ]&quot; at the end. Something like &quot;\&quot;[\w*\.\w*]\&quot;&quot; or similar.Simply ignore strings which don't match that pattern, for example strings which are composed in code like in the weather plugin:[CODE]&nbsp; localizedWord = localization.ToString(&quot;[Weather.&quot;+tokenSplit+&quot;]&quot;);[/CODE]Here, the person using the tool must know what he does, i.e. if the string manager tool says &quot;String Weather.XYZ doesn't seem to be used&quot;, he must know that the weather plugin does such a hack. But that's the problem of code which doesn't explicitly declare globalization strings like the Media plugin does.Later, a function which finds potential matches would be nice. It could scan for the regex pattern &quot;\&quot;[.*]\&quot; for example.In the XAML files, parsing should be more simple, here, the simple regex pattern should always work.In your PM, you asked how to identify plugin dependencies. Such dependencies are defined in the plugin.xml file, you can see an example in the Media plugin. So the string management tool also needs to parse plugin descriptors (the plugin.xml files are called plugin descriptors). The parser class is PluginDirectoryDescriptor.</blockquote>

[QUOTE="Albert, post: 686993, member: 67886"] [b]AW: Globalization string management tool[/b] I absolutely understand your problem with those string instances which are composed at runtime. You're absolutely right, it is not computable which of those dynamic occurences are globalized strings. That's the reason why such a "Find unused strings" function potentially can never find all occurences. Always a user has to look over the result, and the tool must be built to make it possible for the user to check each single search result. The tool should be a help for devs who used localization resources as said in the guidelines (which are not written yet...). That means, in code we have localization string references like this: [CODE] public const string RES_PLAYLIST_LOAD_NO_PLAYLIST = "[Media.PlaylistLoadNoPlaylistText]"; ... dialogManager.ShowDialog(SkinBase.General.Consts.RES_SYSTEM_ERROR, Consts.RES_PLAYLIST_LOAD_NO_PLAYLIST, DialogType.OkDialog, false, null); [/CODE] That example is taken from the [I]Media[/I] plugin. Another way to reference localized strings is to use those placeholders as literal constants in the code like [CODE] SomeMethod("[SomeSection.SomeString]"); [/CODE] To scan both of those strings, you simply need to scan for "[ at the beginning, n alpha-num chars, a dot, n alpha-num chars and ]" at the end. Something like "\"[\w*\.\w*]\"" or similar. Simply ignore strings which don't match that pattern, for example strings which are composed in code like in the weather plugin: [CODE] localizedWord = localization.ToString("[Weather."+tokenSplit+"]"); [/CODE] Here, the person using the tool must know what he does, i.e. if the string manager tool says "String Weather.XYZ doesn't seem to be used", he must know that the weather plugin does such a hack. But that's the problem of code which doesn't explicitly declare globalization strings like the Media plugin does. Later, a function which finds potential matches would be nice. It could scan for the regex pattern "\"[.*]\" for example. In the XAML files, parsing should be more simple, here, the simple regex pattern should always work. In your PM, you asked how to identify plugin dependencies. Such dependencies are defined in the [I]plugin.xml[/I] file, you can see an example in the [I]Media[/I] plugin. So the string management tool also needs to parse plugin descriptors (the plugin.xml files are called plugin descriptors). The parser class is [I]PluginDirectoryDescriptor[/I]. [/QUOTE]

Verification