Using the SmartGWT EE package you've already got (or one downloaded from our website), you can find the BuiltInDS sample at the path samples/built-in-ds under the root of the expanded package. Import that project into Eclipse, and modify it so it reproduces your issue. Then we can take a look.
For more information about using SmartGWT with Development Mode (formerly SuperDevMode), see the appropriate help topic.
Announcement
Collapse
No announcement yet.
X
-
Hi Isomorphic,Originally posted by Isomorphic View PostYou indicate in your last post that you've declared the "en" locale in your GWT project, but from the stack trace in the previous message, it's clear that you're trying to use "de" locale. All locales must be declared in the project file before use.
You've not responded with your GWT version (e.g. 2.7.0, 2.8.2, etc.) as we asked. That's useful information.
We don't beileve AbstractJSON.java is our file, nor is the error string referring to "LocaleDymanicSupport.loadJSONs()".
In our own testing, we don't see any issue with localization not working in the latest SGWT 6.1p release. If you can modify the BuiltInDS project included in the SGWT EE download to reproduce your issue, that would be the quickest way for us to be able to resolve it. Just let us know what modifications you made, and what errors are being reported.
you are absolutely correct regarding the locale we are using which was declared in the project file but the default locale we are using is "en".
And the GWT version we are using is 2.7.0.
As per your previous message by using the SGWT 6.1p, I am getting the issue in console when starting the application on debug mode.
And the above AbstractJSON.java file and LocaleDymanicSupport.loadJSONs() are dynamically generating when hitting the URL- http://127.0.0.1:9876/.
In file or in gwt.xml we dont have any internal changes but as you told, let me know which BuiltInDS project i need to modify to reproduce the issue.
Thank you
Leave a comment:
-
You indicate in your last post that you've declared the "en" locale in your GWT project, but from the stack trace in the previous message, it's clear that you're trying to use "de" locale. All locales must be declared in the project file before use.
You've not responded with your GWT version (e.g. 2.7.0, 2.8.2, etc.) as we asked. That's useful information.
We don't beileve AbstractJSON.java is our file, nor is the error string referring to "LocaleDymanicSupport.loadJSONs()".
In our own testing, we don't see any issue with localization not working in the latest SGWT 6.1p release. If you can modify the BuiltInDS project included in the SGWT EE download to reproduce your issue, that would be the quickest way for us to be able to resolve it. Just let us know what modifications you made, and what errors are being reported.
Leave a comment:
-
Hi,Originally posted by Isomorphic View PostAs per FAQ, please specify the complete version (including release and date stamp) of your SmartGWT when reporting a bug.
What locale are you trying to use? What is the URL that you're hitting? What version of GWT are you using?
Please find the below details which you require
Smart GWT version - 6.1
<extend-property name="locale" values="en"/>
URL- http://127.0.0.1:9876/
While i am enabling Dev mode i am facing the above issue in file AbstractJSON.java
It is working fine with the version 4.1 but not for 6.1
Thank youLast edited by SRD; 20 Jun 2018, 00:55.
Leave a comment:
-
As per FAQ, please specify the complete version (including release and date stamp) of your SmartGWT when reporting a bug.
What locale are you trying to use? What is the URL that you're hitting? What version of GWT are you using?
Leave a comment:
-
Hi Isomorphic,
I am facing the below issue while running the super dev mode for Smart GWT in my local.
Dictionary not loaded. Did you forget to add your instance of com.smartgwt.client.i18n.SmartGwtMessages to LocaleDymanicSupport.loadJSONs() in your module's onLoad?"- MissingResourceException_1_g$
- $fa:true
- className_3_g$:"com.smartgwt.client.i18n.SmartGwtMessages"
- detailMessage_0_g$:"Dictionary not loaded. Did you forget to add your instance of com.smartgwt.client.i18n.SmartGwtMessages to LocaleDymanicSupport.loadJSONs() in your module's onLoad?"
- key_1_g$:"ad"
- stackTrace_1_g$:null
- __gwt$backingJsError:Error: Dictionary not loaded. Did you forget to add your instance of com.smartgwt.client.i18n.SmartGwtMessages to LocaleDymanicSupport.loadJSONs() in your module's onLoad? at StackTraceCreator$CollectorModern_1_g$.collect_2_g$ [as collect_4_g$] (workbench-0.js:19000:38) at captureStackTrace_0_g$ (workbench-0.js:18826:18) at MissingResourceException_1_g$.fillInStackTrace_0_g$ [as fillInStackTrace_1_g$] (workbench-0.js:6802:3) at MissingResourceException_1_g$.Throwable_2_g$ (workbench-0.js:6748:8) at MissingResourceException_1_g$.Exception_2_g$ (workbench-0.js:6894:18) at MissingResourceException_1_g$.RuntimeException_2_g$ (workbench-0.js:15579:18) at new MissingResourceException_1_g$ (workbench-0.js:372687:25) at SmartGwtMessages_de_1_g$.getStringInternal_0_g$ [as getStringInternal_2_g$] (workbench-0.js:48748:11) at SmartGwtMessages_de_1_g$.dialog_OkButtonTitle_0_g$ [as dialog_OkButtonTitle_1_g$] (workbench-0.js:155773:15) at initMessages_0_g$ (workbench-0.js:185287:71) at init_9_g$ (workbench-0.js:185221:5) at SmartGwtSuperDevModeEntryPoint_1_g$.onModuleLoad_4_g$ [as onModuleLoad_7_g$] (workbench-0.js:145912:5) at SmartGwtSuperDevModeEntryPoint_1_g$.onModuleLoad_5_g$ [as onModuleLoad_7_g$] (workbench-0.js:146066:50) at Array.init_2_g$ (workbench-0.js:55023:66) at initializeModules_0_g$ (workbench-0.js:221:30) at apply_0_g$ (workbench-0.js:17848:28) at entry0_0_g$ (workbench-0.js:17918:14) at workbench-0.js:17884:14 at gwtOnLoad_0_g$ (workbench-0.js:234:40) at workbench-0.js:380892:1
- __proto__:Object
Thank you
Leave a comment:
- MissingResourceException_1_g$
-
Thansk for the quick answer !Originally posted by Isomorphic View PostMake sure your injection method causes the locale .js file to be loaded *after* ISC_Core.js and other .js files of the SmartClient runtime are loaded, and before any of your GWT-generated JavaScript application logic runs. That's it.
Got it working now :-)
Leave a comment:
-
Make sure your injection method causes the locale .js file to be loaded *after* ISC_Core.js and other .js files of the SmartClient runtime are loaded, and before any of your GWT-generated JavaScript application logic runs. That's it.
Leave a comment:
-
Can you please elaborate a bit more on this ?Originally posted by Isomorphic View PostYou can indeed load the SmartClient locale files in SmartGWT if you're aware of this advanced technique and able to use it, and if you are not using GWT localization at the application level at all.
We are also using dynamic Dictionary for our translations in our GWT app.
Now we want the build in texts of SmartGWT to be translated.
What I tried is the following :
- Removed all locale stuff from .gwt.xml as this is not needed
- Taken the file : frameworkMessages_fr.properties from smartclient and put in a js folder in our war directory
- Added a script tag to our .html file : <script src="js/frameworkMessages_fr.js"></script>
I can see in the network traffic that the frameWorkMessages_fr.js is loaded but all SmartGWT messages remain in English instead of French.
Are we missing something ?
If we can get this to work it is pretty easy to dynamically inject the correct .js file into the html when the user changes the language.
Leave a comment:
-
You still need to use these special field types if you want the behaviors they provide (automatic formatting and parsing of input, using the conventions of the current locale). And this is what the docs say as well.[*]GWT Internationalization Pros:[LIST][*]Automatic date/currency handling (no need for field type="localecurrency" (or localefloat, localeint)?)
The rest of the list is basically correct, although the benefits you cite as very minor could be argued to be non-existent rather than just minor.
Leave a comment:
-
Hi Isomorphic,
I'm aware of it because you pointed the user in this thread to it.
Is it correct to state this about SmartClient Internationalization compared to GWT I18n (for framework+application):- SmartClient Internationalization Pros:
- No permutation compilation per language
- Add and correct language files while deployed (no recompile)
- Possibility to precache localized strings (very minor)
- GWT Internationalization Pros:
- Automatic date/currency handling (no need for field type="localecurrency" (or localefloat, localeint)?)
- Pruning of unused application strings (very minor)
While reading for this I also hit this in the I18n docs:
I think I'll go that way then if it is the recommended way, even if the "no permutation compilation per language" is very compelling.Application Message Localization
String localization in SmartGWT is best done using standard GWT approaches.
Although GWT supports various ways of localizing strings, Isomorphic recommends the use of an approach based on Resource Bundles.
Other parts of SmartGWT - for example, .ds.xml files - are best localized using resource bundles, so using resource bundles makes it easier to share messages that are used both client and server side.
Best regards,
Blama
Leave a comment:
- SmartClient Internationalization Pros:
-
You can indeed load the SmartClient locale files in SmartGWT if you're aware of this advanced technique and able to use it, and if you are not using GWT localization at the application level at all.
Leave a comment:
-
Hi Isomorphic,
I (perhaps) have difficulties to understand your last post:
Are you referring to the same locales, tgilbert is talking about (myproj.gwt.xml):Originally posted by Isomorphic View PostYes, you need the locales. SmartGWT is using normal GWT localization for framework strings, so even if you use dynamic localization techniques for application strings, you can't just turn off all the locales - that would lead to exactly the result you're seeing.
or are you referring to your javascript locals like in the SmartClient i18n docs:Code:<extend-property name="locale" values="fr"/>
?Code:<SCRIPT SRC="isomorphic/locales/frameworkMessages_pt.properties"></SCRIPT>
If it is the latter, I'm all clear.
Best regards,
Blama
Leave a comment:
-
Yes, you need the locales. SmartGWT is using normal GWT localization for framework strings, so even if you use dynamic localization techniques for application strings, you can't just turn off all the locales - that would lead to exactly the result you're seeing.
Leave a comment:
-
Thanks for your feed-back.
As we use dynamic string internationalization, we have NOT added locales to our module XML file, as we do not need it...
In our XML we only have english, unlike this sample from GWT:
Do we have to add the supported locales like this to support multiple languages in SmartGWT objects?Code:<module> <inherits name="com.google.gwt.user.User"/> <inherits name="com.google.gwt.i18n.I18N"/> <!-- French language, independent of country --> <extend-property name="locale" values="fr"/> <!-- French in France --> <extend-property name="locale" values="fr_FR"/> <!-- French in Canada --> <extend-property name="locale" values="fr_CA"/> <!-- English language, independent of country --> <extend-property name="locale" values="en"/> </module>
Many thanks,
Thomas
Leave a comment:
Leave a comment: