royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Idylog - Nicolas Granon" <>
Subject [Royale] Localization and I8N
Date Sun, 01 Oct 2017 10:22:16 GMT
Ok for the dev royale list.

Thank for your work and information about Validators.
I will definitely have a (deep) look at it.
As you say, it is a good example of the kind of class to which we might contribute to, and
it will be quite instructive to study.
Furthermore, we have an AsyncValidator class that we developed and that allows validations
against a database (or any async function) and that we use heavily for each form input. We
could suggest enhancements in that direction.

Regarding ResourceManager, it is very important to us (and, I believe, for all developers
who target international customers).
We make use of ResourceManager in two principal ways :

- Switching app language at runtime (usually after login screen and before the first "real"
app screen, but it can happen at any time). "app language" meaning not only ui texts but also
formatting rules for numbers and dates
- Assign a locale to a document (all amounts, date, texts of the document will follow the
assigned locale on a per-document basis). Document locale if not always the same than app

There is also some use of ResourceBundle.

Our customers generally have offices in several countries : it implies that the locale depends
on each user's profile. The user's locale is not necessarily the locale of the browser.

So, to answer your questions :

We prefer being able to switch locale at run time (the login screen default locale might be
different from the user preferred locale, plus, the user is allowed to switch his locale at
any point).

We need to be able to instantiate validators/formatters based on an arbitrary locale (possibly
different from the app UI locale).

We also have a custom library which makes use or ResourceManager to perform "two level indirection"
(that is, we create a resource containing customer-specific strings and then we use these
string to perform parametrized getString() calls from another resource. The custom resource
is built at run-time).
(When I say "ResourceManager" it also implies "IResourceManager" !).

We use only western languages locales (FR, EN, DE, IT, ES)

Best regards

Nicolas Granon

> -----Message d'origine-----
> De : Harbs []
> Envoyé : dimanche 1 octobre 2017 04:14
> À :
> Cc :;;
> Objet : Re: [FlexJS] Guidelines for implementation of layout containers
> and navigation containers
> Let’s continue this discussion on the Royale dev list if possible.
> I just implemented the first iteration of Validation. The
> implementation was taken almost verbatim from the old Flex
> implementation. You can follow the process of porting the code in the
> branch here. It should be educational.
> <>
> Additionally I wrote some notes on the process (which is not yet
> finished) in this Google Doc here. It notes differences in classic Flex
> architecture and the new FlexJS/Royale architecture and why a direct
> port is not desirable.
> eZmb3veE/edit?usp=sharing
> <
> EeZmb3veE/edit?usp=sharing>
> I hope it’s helpful in understanding how things are done. If you want
> to get you hands dirty, we’re happy to help. :-)
> Implementing ResourceManager will probably have related considerations.
> Do you need to switch locales at runtime or do you just need to be able
> to specify a locale? A lot of the Flex implementation of
> ResourceManager was designed to deal with the former. I think the vast
> majority of uses probably only need the latter. These are all things
> which need to be considered.
> Thanks,
> Harbs
> > On Sep 28, 2017, at 10:43 PM, Idylog - Nicolas Granon
> <> wrote:
> >
> > Validators (and custom validators), DropdownList... I will not
> enumerate all of them but you understand our needs... Localization is
> also very important to us (ResourceManager) and also quick and flexible
> layout management (but we never use "custom" layouts).

View raw message