Improving localisation

[GoogleCodeExporter]

Hi everybody,

I need some advice on how to proceed, as I would like to clean up the 
localisation resources.

At the moment localisation is done via Resource.get("resource_name").
Most of the UI is designed in NetBeans, which makes sense as changes to the UI 
can be made fast and you know what you will get once the window is opened.

But by using Resource.get() the strings in the designer window are shown as 
"<User Code>" which makes it hard to imagine how the UI will come out in the 
end - see the attached picture of the Settings UI as an example.

There is a proper way to internationalise an application using NetBeans - see 
https://netbeans.org/kb/docs/java/gui-automatic-i18n.html

As I am not deep into i18n in Java and NetBeans I would like to read your 
opinions. This is what I have found out so far.

Pros:
 * UI can designed more efficiently as the outcome is at design time
 * automatic handling of resource IDs based on the widget naming
 * simple translation and preview of the same in the IDE
 * language selector in the main UI could be dropped, as locale is selected based on the users locale automatically

Cons:
 * none from the IDE view, but:
 * current translation would need adaptation to the new resource IDs
 * all translatable code would need to be checked and adapted to the new scheme
 * a new set of .properties file would need to be generated for localisation
 * switching language needs a command line option

So switching to the new scheme is bound to some effort, but this could be done 
step-by-step as both solutions can co-exist during the transition phase.

Existing translations could be reused - the resource names would need 
adaptation, though. But that's what PERL is for. ;)

In the end, all translatable strings would be placed in a new ResourceBundle 
(e.g. JPCSP_<lang>.properties) and the current <lang>.properties files would be 
removed.

I would volunteer to do this as my time permits, as I would like to see the UI 
cleaned up.

What's your opinion?

Greetings,
tempura

Original issue reported on code.google.com by tempura....@gmail.com on 10 Jun 2013 at 8:08

Attachments:

• settings_ui.png

[GoogleCodeExporter]

I don't like the idea to have to use a command-line switch for changing the UI 
language.
The language switch should stay as a menu option.

Original comment by gi...@web.de on 14 Jun 2013 at 7:36

[GoogleCodeExporter]

What about a trade-off? :)

By default the user's locale is to be used. But the user is able to select the 
language of his choice from the menu and after restarting JPCSP the selected 
language would override the locale.

I would not prefer to switch language at runtime, at it needs more 
consideration than starting fresh. Also I don't think user switch languages 
frequently, so this would be a minor annoyance.

Original comment by tempura....@gmail.com on 16 Jun 2013 at 9:42

[GoogleCodeExporter]

Where is the restriction coming from? Are classes from NetBeans to be included 
in the project?

It's OK to have to restart Jpcsp to enable the new language, but the language 
has to be stored in the Settings.properties and users should not have to modify 
startup scripts (e.g. to add command line switches).
A lot of users are often updating the Jpcsp version to test new releases. They 
simply copy the Settings.properties to the new version. This should also work 
for the language.

Original comment by gi...@web.de on 17 Jun 2013 at 10:41

[GoogleCodeExporter]

It's not about NetBeans but Swing. For the language change at runtime each 
widget needs to have setText() called again.

ATM the UI is built again for the MainWindow - which results in no proper 
display (at least for me when I switch to German the buttons revert to 
English). Restarting ensures that the UI is properly displayed and resized for 
the translated strings to fit.

With the trade-off I have mentioned no command line option is necessary as the 
language setting is still stored in Settings.properties.

Users can overrule the system language via menu if they wish not to use their 
system locale - but I believe, that this will only be a small fraction. :)

Original comment by tempura....@gmail.com on 17 Jun 2013 at 5:36

[GoogleCodeExporter]

I have commited the changed in r3625. Please report any regressions here.

Original comment by tempura....@gmail.com on 29 Jun 2013 at 12:43

• Changed state: Started

[GoogleCodeExporter]

So far there seem to be no more regressions, so I will close this issue.

With r3300 all locale codes have been corrected and untranslated strings added 
to the .properties files.

So feel free to update them and send them back to improve the translation.

Thanks!

Original comment by tempura....@gmail.com on 6 Jul 2013 at 7:28

• Changed state: Fixed