Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Scout » ScoutTexts.getText() vs. Texts.getText()(Language Support in Eclipse Scout)
ScoutTexts.getText() vs. Texts.getText() [message #642099] Mon, 29 November 2010 20:22 Go to next message
Lukas Huser is currently offline Lukas HuserFriend
Messages: 42
Registered: March 2010
Member
The Texts class (e.g. com.example.myapp.shared.Texts) is generated by Scout SDK and provides access to the project specific texts (stored in the Texts resource bundle in the shared plugin, e.g. com.example.myapp.shared/resources/texts ).

The ScoutTexts class is provided by the Scout framework (org.eclipse.scout.rt.shared.ScoutTexts) and provides access to texts defined by the framework (examples are labels for common buttons like 'Ok', 'Cancel' and also many texts used in the extended search etc.)

We need to support many different languages in our project and we are actually using an external tool to generate the Texts resource bundle (i.e. the locale-specific Texts_*.properties files).

The current implementation of the Texts and ScoutTexts classes does the following: ScoutTexts loads the ScoutTexts_*.properties files provided in org.eclipse.scout.rt.shared/resources/texts. The Texts class loads both the project specific texts (Texts_*.properties) as well as the framework texts (ScoutTexts_*.properties). Like this, the Texts class provides a single point to access any translated text, whether it has been defined by the framework or by the application itself.

So far, so good. Now here is the point I would like to discuss:
If the same key is defined in both the Texts as well as the ScoutTexts files, the entry within the Texts resource bundle wins.
This is probably not intended/encouraged by the framework designers (?), as for example it is not possible to edit the inherited framework texts in the NLS editor. I would rather see this as a shortcoming of the SDK: If I add a new language (say Afrikaans for example), it is not possible to provide translations for framework texts.

Therefore, it is currently not possible to provide a fully translated application, for example the extended search will remain in English (as the framework relies on the ScoutTexts class).

In my point of view it must be possible to override the translated texts defined by the framework, mainly for two reasons:
(1) The framework texts lack support for many languages, in fact most of the ScoutTexts_*.properties files are virtually empty.
(2) There might be several valid translations for the same English text. Some customer/developer might prefer a different translation for a text (key) defined by the framework.

We already rely on the fact that we can override translated texts in the Texts resource bundle. However, like this, the methods ScoutTexts.getText("myKey") and Texts.getText("myKey") might return different/inconsistent values which is certainly bad.

I therefore would encourage the following change to the Scout framework/SDK:
Any Scout project should be able to override pre-defined texts (translations) defined by the framework.
ScoutTexts.getText() and Texts.getText() MUST return the same value. Any translated text defined by the Scout project must take precedence over the pre-defined translation from the framework.

What do you think?

Greetings,
Lukas
Re: ScoutTexts.getText() vs. Texts.getText() [message #642103 is a reply to message #642099] Mon, 29 November 2010 20:44 Go to previous messageGo to next message
Arthur vD is currently offline Arthur vDFriend
Messages: 52
Registered: March 2010
Member
Good input. Would we still need ScoutTexts.getText() at all if we would follow your proposal? What's the reasoning for having both currently?

Regards

Arthur
Re: ScoutTexts.getText() vs. Texts.getText() [message #642127 is a reply to message #642099] Tue, 30 November 2010 00:03 Go to previous messageGo to next message
Lukas Huser is currently offline Lukas HuserFriend
Messages: 42
Registered: March 2010
Member
Yes, you're right, if Texts and ScoutTexts do the same, we probably could drop one of them (for example, we could end up with a single Texts class provided by the framework, where multiple providers could register resource bundles). However, if we drop one of the classes we change the interface on how to retrieve texts and someone needs to migrate existing code (either the framework, or existing projects, or both).

Btw. the static method is actually called Texts.get() and not Texts.getText(), just in case someone got confused... Smile
Re: ScoutTexts.getText() vs. Texts.getText() [message #642216 is a reply to message #642127] Tue, 30 November 2010 12:24 Go to previous messageGo to next message
Nicolas Born is currently offline Nicolas BornFriend
Messages: 1
Registered: November 2010
Junior Member
hi lukas

i support your proposition.

regards,
nick
Re: ScoutTexts.getText() vs. Texts.getText() [message #642250 is a reply to message #642099] Tue, 30 November 2010 15:11 Go to previous messageGo to next message
Eclipse UserFriend
I totally agree with your propose. What has to be discussed now is how
such a behavior has to be implemented? If it would be that easy as
1..2.. we would have implemented it this way.
But people getting smarter. The solution for such a behavior would be to
provide a INlsTextService. A service has the mentioned scope of a scout
project (environment) and can easily be overloaded (service ranking).

@Lukas: could you please open a Bugzilla?

BR
andy


On 29.11.2010 21:22, Lukas Huser wrote:
> The Texts class (e.g. com.example.myapp.shared.Texts) is generated by
> Scout SDK and provides access to the project specific texts (stored in
> the Texts resource bundle in the shared plugin, e.g.
> com.example.myapp.shared/resources/texts ).
> The ScoutTexts class is provided by the Scout framework
> (org.eclipse.scout.rt.shared.ScoutTexts) and provides access to texts
> defined by the framework (examples are labels for common buttons like
> 'Ok', 'Cancel' and also many texts used in the extended search etc.)
>
> We need to support many different languages in our project and we are
> actually using an external tool to generate the Texts resource bundle
> (i.e. the locale-specific Texts_*.properties files).
>
> The current implementation of the Texts and ScoutTexts classes does the
> following: ScoutTexts loads the ScoutTexts_*.properties files provided
> in org.eclipse.scout.rt.shared/resources/texts. The Texts class loads
> both the project specific texts (Texts_*.properties) as well as the
> framework texts (ScoutTexts_*.properties). Like this, the Texts class
> provides a single point to access any translated text, whether it has
> been defined by the framework or by the application itself.
> So far, so good. Now here is the point I would like to discuss:
> If the same key is defined in both the Texts as well as the ScoutTexts
> files, the entry within the Texts resource bundle wins.
> This is probably not intended/encouraged by the framework designers (?),
> as for example it is not possible to edit the inherited framework texts
> in the NLS editor. I would rather see this as a shortcoming of the SDK:
> If I add a new language (say Afrikaans for example), it is not possible
> to provide translations for framework texts.
>
> Therefore, it is currently not possible to provide a fully translated
> application, for example the extended search will remain in English (as
> the framework relies on the ScoutTexts class).
>
> In my point of view it must be possible to override the translated texts
> defined by the framework, mainly for two reasons:
> (1) The framework texts lack support for many languages, in fact most of
> the ScoutTexts_*.properties files are virtually empty.
> (2) There might be several valid translations for the same English text.
> Some customer/developer might prefer a different translation for a text
> (key) defined by the framework.
>
> We already rely on the fact that we can override translated texts in the
> Texts resource bundle. However, like this, the methods
> ScoutTexts.getText("myKey") and Texts.getText("myKey") might return
> different/inconsistent values which is certainly bad.
> I therefore would encourage the following change to the Scout
> framework/SDK: Any Scout project should be able to override pre-defined
> texts (translations) defined by the framework.
> ScoutTexts.getText() and Texts.getText() MUST return the same value. Any
> translated text defined by the Scout project must take precedence over
> the pre-defined translation from the framework.
>
> What do you think?
>
> Greetings,
> Lukas
>
Re: ScoutTexts.getText() vs. Texts.getText() [message #642464 is a reply to message #642250] Wed, 01 December 2010 13:15 Go to previous message
Arthur vD is currently offline Arthur vDFriend
Messages: 52
Registered: March 2010
Member
Opened bug 331535. Regards, Arthur.
Previous Topic:Scout and E4?
Next Topic:Questions: Scout Source Code Repository / Roadmap
Goto Forum:
  


Current Time: Mon Nov 11 06:54:29 GMT 2024

Powered by FUDForum. Page generated in 0.25658 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top