| ScoutTexts.getText() vs. Texts.getText() [message #642099] |
Mon, 29 November 2010 20:22  |
 Lukas Huser
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 #642127 is a reply to message #642099] |
Tue, 30 November 2010 00:03  |
Lukas Huser
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... 
|
|
|
|
| Re: ScoutTexts.getText() vs. Texts.getText() [message #642250 is a reply to message #642099] |
Tue, 30 November 2010 15:11 |
Eclipse User |
|
|
|
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
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.03628 seconds
] 
Search
Help
Register
Login
Home
