Externalize all Strings within the GWT UI using GWT i18n

[GoogleCodeExporter]

Much of the GWT UI is i18n'ized, but there are still some parts that need 
externalizing.

Original issue reported on code.google.com by asgeirf on 24 May 2010 at 12:49

[GoogleCodeExporter]

Start this one now. Will get beck to Issue#63 after the 4 tickets are done.

Will put the plan of Resource files here.

Original comment by Caius.Chance on 31 May 2010 at 2:21

• Changed state: Started

[GoogleCodeExporter]

Just clarifying the scope of this task:
 - Externalize remaining textual strings
 - Create translation for another language to test with
 - Hook in to some sort of language selection, e.g. based on browser language or user-selected language.
 - In the end, the language in the JSF and GWT part should be managed identically, i.e. if the language in the JSF pages is Japanese, the editor should also start in Japanese.

Original comment by asgeirf on 10 Jun 2010 at 12:36

[GoogleCodeExporter]

All UI messages should be externalized. The log and exception messages are not 
included.

Added sample French translation for WebTransMessages.java: 
WebTransMessages_fr.properties.

Add "&locale=fr" at translation editor to test.

Original comment by Caius.Chance on 11 Jun 2010 at 6:11

• Added labels: Component-UI, Usability

Attachments:

• Issue102.diff

[GoogleCodeExporter]

I think you forgot to add WebTransMessages_fr.properties to the diff.

Original comment by asgeirf on 11 Jun 2010 at 6:14

[GoogleCodeExporter]

sorry

Original comment by Caius.Chance on 11 Jun 2010 at 6:19

Attachments:

• Issue102.diff

[GoogleCodeExporter]

My personal ref#:

http://seamframework.org/Documentation/HowDoesTheDefaultLocaleWorkWhenIsItUsed

http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/5.0.1/htm
l/Seam_Reference_Guide/locales.html

Original comment by Caius.Chance on 15 Jun 2010 at 5:17

[GoogleCodeExporter]

My current patch on this issue. I added a language change facility for locale 
change for current session.

Original comment by Caius.Chance on 16 Jun 2010 at 12:18

Attachments:

• Issue102.diff

[GoogleCodeExporter]

All strings are externalized from GWT UI.

There are two types of sources -.java file and .ui.xml (UiBinder file). They 
are both extracted.

The filename of auto-gen .properties file of UiBinder files should not be 
renamed. Otherwise, it will not link up.

Original comment by Caius.Chance on 24 Jun 2010 at 3:59

[GoogleCodeExporter]

Good stuff. How have you tested that you have externalized all strings? I don't 
think we can close this until we have it tested with either:
1) A pseudo-translated site using e.g. character substitution like "Ŧlเєร 
ฬє๒ tгคภรlคtเ๏ภ" - This should be somewhat auto-generated 
so that we can keep it when we add new features as well. E.g. input is english 
properties file and output is pseudo translated property file.
2) A real translated site in e.g. Japanese or Chinese. 

This goes for both the GWT and JSF parts.

Original comment by asgeirf on 28 Jun 2010 at 3:56

[GoogleCodeExporter]

Added sample Italian translation for JSF, sourced from outputs of Google 
Translate.

Original comment by Caius.Chance on 30 Jun 2010 at 1:20

[GoogleCodeExporter]

There is only non-locale-suffixed .properties files in repo now. The 
*_qc.properties testing files are generated during compile. There are maven 
scripts need for some file copying/moving to be automated.

Original comment by Caius.Chance on 1 Jul 2010 at 5:37

[GoogleCodeExporter]

There is only non-locale-suffixed .properties files in repo now. The 
*_qc.properties testing files are generated during compile. There are maven 
scripts need for some file copying/moving to be automated.

Original comment by Caius.Chance on 1 Jul 2010 at 5:39

[GoogleCodeExporter]

I changed match pattern and output directory of pseudo translation plugin, 
removed set-property of en as locale, and ignored generated *_qc.properties 
files in src/main/resources/.

Original comment by Caius.Chance on 2 Jul 2010 at 12:59