how to get locale information on a GWT application - url

In GWT I have to specify what locales are supported in my application. The code get compiled in various files, one for each locale (beside other versions), but I have to give my clients one only URL. This URL is supposed to be a page that should be displayed according to the locale preferred by the browser.
I dont't want to have an HTTP parameter for the locale since I want to forse the locale preferred by the browser.
How can this be coded in GWT?
Should I try to to this using apache rewrite rules? I thied it, but I think I cannot access such parameter easely in a rewrite rule.
Thanks a lot,
Giuseppe

I had the same problem as you, but as I really need to know the current locale (I'm requesting a second server for data that I want to be localizable) I found this class:
com.google.gwt.i18n.client.LocaleInfo#getCurrentLocale(). That should give you what GWT uses currently.

GWT has good support for internationalization. See this link. The i18nCreator command can help you to set up the internationalization infrastructure for similar to the way projectCreator and applicationCreator set up the GWT application.
If you have static strings (i.e. Invalid Entry!) that need to be internationalized, you don't need any additional flag to i18nCreator command to create the properties files and infrastructure.
If you have strings that need to accept parameters (i.e. Hello {0}), you need to pass the -createMessages flag to i18nCreator command to create the properties files and infrastructure.
Now your module needs to include the i18n module in your MyApplication.gwt.xml:
<inherits name="com.google.gwt.i18n.I18N"/>
Define a Java interface in the same package as your property files that extends Constants or Messages and defines methods (name matches the property entries) that all return string.
MyConstants.properties contains:
errorMessage=Invalid Entry!
MyConstants.java contains:
import com.google.gwt.i18n.client.Constants;
public interface myConstants extends Constants {
String errorMessage();
}
Now to access these internationalized Strings from you application:
public class MyApplication implements EntryPoint {
private static final MyConstants constants = (MyConstants)GWT.create(MyConstants.class);
public void onModuleLoad() {
final Label errorMessage = new Label(constants.errorMessage);
}
}
GWT implements the interface for you automagically.
You can get messages in a similar way.
Hopefully this can help you get started.

Unless I am reading the documentation incorrectly I don't think you have to do anything.
GWT and Locale
By making locale a client property, the standard startup process in gwt.js chooses the appropriate localized version of an application, providing ease of use (it's easier than it might sound!), optimized performance, and minimum script size.
The way I read it, as long as your module has added all the locale choices to it, it should be automatic?

Check this com.google.gwt.i18n.client.LocaleInfo.getCurrentLocale()

<inherits name="com.google.gwt.i18n.I18N"/>
<!-- Use browser-specified locale for i18n -->
<set-configuration-property name="locale.useragent" value="Y"/>
<!-- Specify locales your application support -->
<extend-property name="locale" values="en"/>
<extend-property name="locale" values="de_DE"/>
<extend-property name="locale" values="ru_RU"/>

Related

Sublime Text 3 - Set syntax for filetype in package/plugin

I am busy making a sublime text plugin/package that will ease development of lua scripts in my workplace.
We have several lua files with different extensions depending on their purpose. I want ST3 to give the proper lua syntax to these files.
I know you can set ST3 to remember syntax for a specific file extension and this is saved as a (in my case) Lua.sublime-settings file in AppData\Roaming\Sublime Text 3\Packages\User
However, if I put this file in my new plugin's folder, it's ignored.
Am I doing something wrong or is what I want not possible?
This doesn't work because syntax specific settings are only loaded from the package that defines the syntax and from the User package (so the user can customize them).
The following is a quote from the official documentation on settings:
Settings files are consulted in this order:
1. Packages/Default/Preferences.sublime-settings
2. Packages/Default/Preferences (<platform>).sublime-settings
3. Packages/User/Preferences.sublime-settings
4. <Project Settings>
5. Packages/<syntax>/<syntax>.sublime-settings
6. Packages/User/<syntax>.sublime-settings
7. <Buffer Specific Settings>
The only places where <syntax> is referenced is from the package itself and from the user package.
If I had to guess, I would say that this is because outside of the original package author that defined the syntax, all other settings would be considered user customizations, and those settings need to be in the User package (specifically in the root of it) to ensure that they're loaded last.
A simple (but undesirable) solution would be to document for the user that they have to take this step manually.
Another approach would be to add some plugin code that extends the settings when your plugin is loaded:
def plugin_loaded():
settings = sublime.load_settings("Lua.sublime-settings")
extensions = settings.get("extensions", [])
if "blarb" not in extensions:
extensions.append("blarb")
settings.set("extensions", extensions)
sublime.save_settings("Lua.sublime-settings")
If you go this route you may want to include an extra sentinel setting somewhere (in settings specific to your package or some such) that says if you did this or not instead of just forcing the setting in as the example above does.
In practice you would then check if you've set that sentinel or not instead of forcing the extension in, so that if the user decides to use some other syntax for your files you're not forcing them into the Lua syntax.
It's also possible to define your own syntax that just embeds the standard Lua syntax, which allows this to Just Work™ without having to write any code or have the user do anything:
%YAML 1.2
---
name: Blarb
scope: source.lua
file_extensions:
- blarb
contexts:
main:
- include: scope:source.lua
When you do this, the scope in the file will still be source.lua because that's what the scope in the syntax file says. and the status line will set the syntax name to Blarb. You could modify either of those to change the top level scope or displayed name, if desired.
An example would be to change the scope to source.blarb so that you could create key bindings/snippets that only apply to Lua files of your specific variant.
A potential downside/feature of this is that since the name of the syntax specific settings comes from the name of the file that provides the syntax, if the user has any Lua specific settings, they won't apply to your Blarb files by default.
Similarly anything that's specific to Lua by checking for a scope of source.lua won't work in Blarb files for same reasons, which may or may not be an issue.

Does ApplicationRessource.properties file can be in another locale than EN

Is the Struts2 file applicationRessource.properties can be in another locale than English. I know I can have some other files like ApplicationRessource_fr.properties or ApplicationRessource_es.properties.
My main questions concern only the ApplicationRessource.properties. My default language will be French and I don't want to have a file like ApplicationRessource_fr.properties. Is there a way to do that?
You must have a file like ApplicationRessource_fr.properties if you want to use French locale. You can also have a default language file which will be used if no locale is requested. The essential part of the application include the interceptor to intercept the requested locale, you can also switch the locale per request.
It's likely no i18n interceptor on the action stack or you don't have
resource bundles for the used locale or default locale used by the
JVM.
Essentially, the i18n Interceptor pushes a locale into the ActionContext map upon every request. The framework components that
support localization all utilize the ActionContext locale.
Here was the solution we found. We use 3 files. ApplicationRessource.properties who are in french, ApplicationRessource_fr.properties who is empty and ApplicationRessource_en.properties who contains the english translations

zend framework 2 - Translation Process

i am developing web app with ZF2. It is a multilingual website. I would like to use ZF2 Translator for translation. Because, admin can modify the language variables. So, i planned to use the language folder files. I will update the language files while the admin modifying the language variables. Can anyone suggest ideas for this implementation? Thanks.
Translating based on user input can get a little messy. There is no easy way of doing that right now, as the currently supported formats are all file formats: php files with arrays, a gettext .po file or Tmx/Xliff files. For the easiest access, you would likely store the translations in a database.
You therefore need to write your own loader, loading the translations from the database. An alternative is you will write the translations in a php array and export that to a file, but I would not recommend that. For the database loader, you must implement the RemoteLoaderInterface. In very simple terms:
use My\DbTable;
use Zend\I18n\Translator\Loader\RemoteLoaderInterface;
Zend\I18n\Translator\TextDoamin;
class DbLoader implements RemoteLoaderInterface
{
protected $table;
public function __construct(DbTable $table)
{
$this->table = $table;
}
public function load($locale, $textDomain)
{
$data = $this->table->loadFromLocale($locale);
// process $data into $messages
// $messages is array(key=>value) with key translation key
$domain = new TextDomain($messages);
return $domain;
}
}
The db table loads the messages in the locale you specify. If you use text domains, pass that on too. Then you need to configure your Translator such it uses this loader too to load the message. Everything else should be fine then. In your views, you can create translations like this:
<?php echo $this->translate('my original text'); ?>
The SkeletonApp comes with Translation support built-in. However further details on how to use it can also be found in the manual -> http://zf2.readthedocs.org/en/latest/modules/zend.i18n.translating.html
I personally keep all my language files in a folder called /language
In your views you could also simply call
$this->translate('text_you_want_to_translate');

How can I find out what Change template a DOORS Module is using?

I need to use DXL to loop through all modules in our database and find out which Rational Change Template each module is using, and possibly switch it to a different one. Can't find any documentation on Change API for DOORS.
I had to contact IBM directly to get this information. But here it is if anyone else needs to do it.
Skip cfgData = createString
string current_template = ""
getModuleConfigurationData(m, cfgData)
find(cfgData, CSINT_CONFIG_USE_TEMPLATE, current_template)
delete cfgData
At this point current_template has the file name of the template that it is configured for. This can be used to compare to existing templates and verify it is set correctly.
Also, if an update is necessary the following function will save the skip list back to the configuration.
put(cfgData, CSINT_CONFIG_USE_TEMPLATE, new_template)
cmSaveModuleConfigurationData(m, cfgData)

Overriding JSF's default I18N handling

Like the asker of the question here
Variable substitution JSF Resource Bundle property file
I'm slightly aghast at the inability to reference the value of other property keys in the message bundle.
Although I see how easy to write my own rubbish handler[0] that can do what I want in a custom component, that would leave expressions in templates calling the message bundle still using the default JSF implementation.
Is it possible to override the default JSF handling of the message bundle?
[0] Or better, to use code referenced in one of the answers to the above question
https://code.google.com/p/reflectiveresourcebundle/
You can provide the fully qualified name of a concrete ResourceBundle implementation as "base name" instead of alone the path and filename of the properties files.
E.g.
public class YourCustomResourceBundle extends ResourceBundle {
// ...
}
which can be registered as follows
<application>
<resource-bundle>
<base-name>com.example.YourCustomResourceBundle</base-name>
<var>text</var>
</resource-bundle>
</application>
or declared on a per-view/template basis as follows
<f:loadBundle baseName="com.example.YourCustomResourceBundle" var="text" />
Here are several related questions/answers which contain some concrete code which you could use as a kickoff example:
How to remove the surrounding ??? when message is not found in bundle
internationalization in JSF with ResourceBundle entries which are loaded from database
i18n with UTF-8 encoded properties files in JSF 2.0 appliaction
Everything is possible for those who try. The question is not whether it is is possible but should you do it. And the answer to that question is: probably not.
Referencing other message in a message bundle means you want to build a compound message. So you can re-use part of the message many times just to save small fraction of the disk space or small fraction of development time.
If that is the case, I have a message for you. What you plan to do is called a concatenation and it is the second most common I18n defect. And its implications are as bad as those of hardcoded strings.
Why? Because target languages do not follow the English grammar rules. First, it is common need to re-order the sentence while translating. This might be easy to fix by using (numbered or named) placeholders. On the other hand though, the translation might differ depending on the context. That is, it might need to be translated in totally other way, or simply the word endings might need to be different depending on a grammar case, mood or gender.
My advice is, do not use such shortcuts, it will create more problems than it fixes.
Now you should know why "those stupid Romans" didn't implement it like this: it is against I18n best practices.

Resources