Suggestion for I18N for context menus

[GoogleCodeExporter]

To simplify internationalization of context menus I added a method to 
JarServiceProvider:
public static Properties readProperties(String name, Locale locale)

In contrast public static Properties readProperties(String name) this method 
takes an additional Locale parameter used for overriding properties of the 
default properties file with properties from a language specific file. The 
method reads the properties as follows:
- 1st it reads properties from the default file (<name>.properties)
- 2nd it reads properties from language specific file 
(<name>_<lang>.properties, where <lang> is language of Locale parameter) and 
merges them with properties of step 1
- 3rd it reads properties from language/country specific file 
(<name>_<lang>_<country>.properties, where <country> is country of Locale 
parameter) and merges them with properties read in previous steps

If you want to have configurations for multiple languages, most of 
configuration is identical for all langauges (e.g. classnames for action 
classes, logical structure of menu).
Usually I'd expect that only ToolTip and MenuText would have to be different 
for each language.
Using this method, you could have one general configuration file which includes 
all properties, including menu text and tooltips for the default language.
For other languages you would only need to define those properties which differ 
from the default, i.e. MenuText, ToolTip...

For example you could have
- config.properties which includes the complete configuration for English GUI
- config_de.properties which only includes German .MenuText and .ToolTip entries
- config_de_CH.properties which consists only of specific overrides for 
Switzerland (as Swiss German has different spelling for some words)

I also changed DefaultSyntaxKit.loadConfig to use this new method, so that 
automatically the default locale is used.
That way, a developer could use JSyntaxPane "out of the box" and to support new 
localization for the menus he'd only have to provide the _<lang>.properties 
variant of the configuration somewhere in his project.

Original issue reported on code.google.com by martin.z...@consol.de on 8 Jul 2010 at 7:41

Attachments:

• locale_patch.txt

[GoogleCodeExporter]

Sounds great.
I'll have a look at put in trunk as soon as i have a chance.
Do you have sample Locale changes?
And of course, a legal note, that all of the changes are under the Apache 
Licence yada yada... :-)

Original comment by ayman.al...@gmail.com on 8 Jul 2010 at 1:12

• Changed state: Accepted

[GoogleCodeExporter]

Legal note: All the changes I provide here are under the Apache Licence 
(Do you need anything else or is that good enough?)

I tested a bit further and found (and fixed) 3 small problems with my first 
attempt:

1.) Encoding of localized configuration: Previously the default platform 
encoding was used which differs (e.g. CP1252 on German Windows, UTF-8 on most 
Linux system etc.). I made yet another small change to JarServiceProvider to 
always use UTF-8 (which shouldn't make any difference to the existing English 
files)

2.) Popup menu which contains submenu (e.g. "Surround with" for JavaSyntax): To 
properly localize the "Surround with" menu entry in my old version one would 
have to copy the whole PopupMenu property to the localized configuration and 
then change the one string to a localized version. Instead I added a property 
"SURROUND_WITH" to default English configuration and reference this in 
PopupMenu via ${SURROUND_WITH}. That way the localized config only needs to 
translate this one property.

3.) Because JarServiceProvider.readProperties always uses lowercase filename my 
earlier description was wrong: Swiss config file would have to be named 
"config_de_ch.properties", not "config_de_CH.properties"

I attached a revised version of the locale patch file (replaces the earlier 
version) as well as an example for German configuration. To see the German 
configuration you can start SyntaxTester e.g. with 
java -Duser.language=de -cp jsyntaxpane_resources_de.jar;jsyntaxpane-0.9.5.jar 
jsyntaxpane.SyntaxTester

This jar file contains only translations for default kit and javasyntaxkit, so 
there might be some remaining English menu entries for other kits.

Original comment by martin.z...@consol.de on 14 Jul 2010 at 11:47

Attachments:

• locale_patch_new.txt
• jsyntaxpane_resources_de.jar

[GoogleCodeExporter]

Looking at these now

Original comment by ayman.al...@gmail.com on 21 Jul 2010 at 6:50

[GoogleCodeExporter]

I created a new branch, finally after several failed attempts and screwing up 
the repo.
I18n will be in r0.9.6 for now and then shortly put into trunk.
see r144

Original comment by ayman.al...@gmail.com on 21 Jul 2010 at 8:58

[GoogleCodeExporter]

Thanks, that's great news :)

Original comment by martin.z...@consol.de on 21 Jul 2010 at 9:01

[GoogleCodeExporter]

Hello, 

an exception prevents the ReplaceDialog from starting when there is no bundle 
for the current locale. The following patch fixes it:
http://patch-tracker.debian.org/patch/series/view/libjsyntaxpane-java/0.9.6~r156
-4/load-bundle-i18n

Bye, Mt

Original comment by martin.q...@ens-rennes.fr on 21 Aug 2013 at 9:44

Attachments:

• load-bundle-i18n