What is the best way to override specific localization Strings, which are stored in the property files?
Announcement
Collapse
No announcement yet.
X
-
If you're adding new messages for untranslated strings or improving upon the existing messages in a general purpose way, contribute the translations here and they will be included in future nightlies/released.
If you are trying to maintain private changes for some reason, just edit the files and be sure not to overwrite them (or merge as needed) on upgrade.
-
Your other option to make customized translations is the following :
Code:ModifiedSmartgwtMessages customizedMessages = GWT.create(ModifiedSmartgwtMessages.class); I18nUtil.initMessages(customizedMessages);
Code:import com.smartgwt.client.i18n.SmartGwtMessages; public interface ModifiedSmartgwtMessages extends SmartGwtMessages { @Override String listGrid_sortFieldAscendingText(); }
Code:listGrid_sortFieldAscendingText=Customized text
Comment
-
version: SmartGWT 3.0
The following methods cannot override. Other methods can override.
@Override
String multiSortDialog_levelDownPrompt();
@Override
String multiSortDialog_levelUpPrompt();
It was not able to do, even if it used directly under "onModuleLoad()" and "initialization Brock".
Please let me know what is required in order to override.
Comment
-
#7>
Thank you for showing a properties file.
What is the SmartGWT version of shown Properties?
I can think that a SmartGWT term exists and has not made a mistake in a definition.
However, it is unrealizable.
NG>multiSortDialog_levelDownPrompt()
NG>multiSortDialog_levelUpPrompt()
OK>multiSortDialog_firstSortLevelTitle()
Is this Bug of SmartGWT?
Comment
-
Hi. I just wanted to share how we resolved the issue of overriding translation strings. We didn't want to get into the problem of riding the SmartGWT bleeding edge release, so some means of back-patching the fixes was needed.
=== Option 1: Reconstruct JAR ===
The first option, which I do not actually dislike, is to simply re-package the smartgwt jar with modified SmartGwtMessages_XX.properties files--being sure to apply a new Maven group/artifact ID to indicate that it's non-standard.
The upside of this is that anyone rolling the SmartGWT version in your projects is going to immediately notice the strange group/artifact ID and be forced to carefully fixes to the new release.
The downside is that this isn't necessarily intuitive to manage in a source code repository.
=== Option 2: Inject new Implementation at Runtime ===
(I retracted my previous comments. smartgwt.dev did a better job of explaining this above. I documented my solution before actually reading this thread.) :)Last edited by TheUserRyan; 14 Dec 2011, 15:11.
Comment
Comment