Localization

[Hugo Ferreira <hf...@gmail.com>]

What's the recommended approach for localization in Royale ?
An out of the box API that grabs a txt file with the key/values ?

Re: Localization

[Harbs <ha...@gmail.com>]

Glad you liked the idea. :-)

> On Jul 2, 2020, at 10:19 PM, Hugo Ferreira <hf...@gmail.com> wrote:
> 
> I just implemented my own LocaleManager.
> I have an interface, AS languages files that ensures that implements all
> keys (with Flex we don't have this and happens to missing keys) and my own
> LocaleManager.
> Super cool and framework independent.
> 
> Thank you.
> 
> Harbs <ha...@gmail.com> escreveu no dia quarta, 1/07/2020 à(s) 07:32:
> 
>> [ResourceBundle] has support, but I’m pretty sure that’s in mx. You can
>> probably use it even if you’re not using mx components (I think).
>> 
>> I’ve always used my own home-grown method of loading locale strings and
>> construct them into an object which is read using keys.
>> 
>> i.e. LocaleManager.localeStrings.OK
>> 
>> Besides the fact that I hate “magic”, this has the advantage of allowing
>> me to make localeStrings a typed class so I get type checking on the actual
>> strings to prevent mistakes...
>> 
>> HTH,
>> Harbs
>> 
>>> On Jul 1, 2020, at 3:14 AM, Hugo Ferreira <hf...@gmail.com>
>> wrote:
>>> 
>>> What's the recommended approach for localization in Royale ?
>>> An out of the box API that grabs a txt file with the key/values ?
>> 
>> 

Re: Localization

[Hugo Ferreira <hf...@gmail.com>]

I just implemented my own LocaleManager.
I have an interface, AS languages files that ensures that implements all
keys (with Flex we don't have this and happens to missing keys) and my own
LocaleManager.
Super cool and framework independent.

Thank you.

Harbs <ha...@gmail.com> escreveu no dia quarta, 1/07/2020 à(s) 07:32:

> [ResourceBundle] has support, but I’m pretty sure that’s in mx. You can
> probably use it even if you’re not using mx components (I think).
>
> I’ve always used my own home-grown method of loading locale strings and
> construct them into an object which is read using keys.
>
> i.e. LocaleManager.localeStrings.OK
>
> Besides the fact that I hate “magic”, this has the advantage of allowing
> me to make localeStrings a typed class so I get type checking on the actual
> strings to prevent mistakes...
>
> HTH,
> Harbs
>
> > On Jul 1, 2020, at 3:14 AM, Hugo Ferreira <hf...@gmail.com>
> wrote:
> >
> > What's the recommended approach for localization in Royale ?
> > An out of the box API that grabs a txt file with the key/values ?
>
>

Re: Localization

[Hugo Ferreira <hf...@gmail.com>]

I never liked ResourceBundle tag too but it was what I had with Flex.
Here in a new application is also a new opportunity to do better but I will
have to use what we have.
I liked the way that Harbs mentioned it.

Carlos Rovira <ca...@apache.org> escreveu no dia quarta, 1/07/2020
à(s) 09:55:

> In Jewel you can check Validator.as
> It implements resourceManager
> through a bead: iLocalizedValuesImpl
>
> but I remember talking with Alex that was not a good idea, or maybe we can
> improve it. But it's something to improve for the future.
>
> I never liked the ResourceBundle tag, and in fact never use it in real Apps
> since we used translations from Java Spring.
> But Royale UI Sets should have something built-in to deal with things like
> form validator error messages, but not the way is done currently
> where we "bake" language messages on it.
>
> Is something to think about it...
>
>
> El mié., 1 jul. 2020 a las 8:32, Harbs (<ha...@gmail.com>) escribió:
>
> > [ResourceBundle] has support, but I’m pretty sure that’s in mx. You can
> > probably use it even if you’re not using mx components (I think).
> >
> > I’ve always used my own home-grown method of loading locale strings and
> > construct them into an object which is read using keys.
> >
> > i.e. LocaleManager.localeStrings.OK
> >
> > Besides the fact that I hate “magic”, this has the advantage of allowing
> > me to make localeStrings a typed class so I get type checking on the
> actual
> > strings to prevent mistakes...
> >
> > HTH,
> > Harbs
> >
> > > On Jul 1, 2020, at 3:14 AM, Hugo Ferreira <hf...@gmail.com>
> > wrote:
> > >
> > > What's the recommended approach for localization in Royale ?
> > > An out of the box API that grabs a txt file with the key/values ?
> >
> >
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>

Re: Localization

[Carlos Rovira <ca...@apache.org>]

In Jewel you can check Validator.as
It implements resourceManager
through a bead: iLocalizedValuesImpl

but I remember talking with Alex that was not a good idea, or maybe we can
improve it. But it's something to improve for the future.

I never liked the ResourceBundle tag, and in fact never use it in real Apps
since we used translations from Java Spring.
But Royale UI Sets should have something built-in to deal with things like
form validator error messages, but not the way is done currently
where we "bake" language messages on it.

Is something to think about it...


El mié., 1 jul. 2020 a las 8:32, Harbs (<ha...@gmail.com>) escribió:

> [ResourceBundle] has support, but I’m pretty sure that’s in mx. You can
> probably use it even if you’re not using mx components (I think).
>
> I’ve always used my own home-grown method of loading locale strings and
> construct them into an object which is read using keys.
>
> i.e. LocaleManager.localeStrings.OK
>
> Besides the fact that I hate “magic”, this has the advantage of allowing
> me to make localeStrings a typed class so I get type checking on the actual
> strings to prevent mistakes...
>
> HTH,
> Harbs
>
> > On Jul 1, 2020, at 3:14 AM, Hugo Ferreira <hf...@gmail.com>
> wrote:
> >
> > What's the recommended approach for localization in Royale ?
> > An out of the box API that grabs a txt file with the key/values ?
>
>

-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Localization

[Andrew Wetmore <co...@gmail.com>]

@Harbs <ha...@gmail.com>  does your solution allow for switching
locales once the app is running? A standard Canadian use case is to be able
to jump from the English to the French version of the app without losing
data or workflow. That is the feature of the standard method for
localization that I have always relied on.

That said, I have long delayed writing either the docs or page in the
getting-started tutorial about localization. I guess I should do that now!
Could I draw on your wisdom; perhaps get you to review what I write?

Andrew

On Wed, Jul 1, 2020 at 6:53 AM Hugo Ferreira <hf...@gmail.com> wrote:

> Very good.
> I will follow the same approach.
> Never liked the Flex way.
>
> Harbs <ha...@gmail.com> escreveu no dia quarta, 1/07/2020 à(s)
> 10:49:
>
> > I don’t actually propagate changes. In my case, all localization is
> > determined at launch time. I have a RuntimeOptions class which gets
> runtime
> > options from url parameters (using a ApplicationParametersCaseInsensitive
> > bead). One of the runtime options in locale.
> >
> > Currently, I’m bundling all localized strings in the actual app. That
> adds
> > a non-insignificant weight to the app, so someday, I’ll probably pull the
> > strings out and load them as-needed.
> >
> > Either way, here’s the current full LocaleManager class:
> > https://paste.apache.org/17dzh <https://paste.apache.org/17dzh>
> >
> > I have some cruft from old implementations and some which will hopefully
> > be improved in the future, but you should get the idea.
> >
> > IUIStrings contains all the definitions.
> >
> > > On Jul 1, 2020, at 11:33 AM, Hugo Ferreira <hf...@gmail.com>
> > wrote:
> > >
> > > "this has the advantage of allowing me to make localeStrings a typed
> > class
> > > so I get type checking on the actual strings to prevent mistakes"
> > >
> > > That's a very good idea !
> > > I never liked the way that Flex deals with that and sometimes there are
> > > type check errors that I can only see at runtime.
> > >
> > > Can you give an example, how the value changed (language value) in the
> > > constant: LocaleManager.localeStrings.OK ?
> > >
> > > Harbs <ha...@gmail.com> escreveu no dia quarta, 1/07/2020 à(s)
> > 07:32:
> > >
> > >> [ResourceBundle] has support, but I’m pretty sure that’s in mx. You
> can
> > >> probably use it even if you’re not using mx components (I think).
> > >>
> > >> I’ve always used my own home-grown method of loading locale strings
> and
> > >> construct them into an object which is read using keys.
> > >>
> > >> i.e. LocaleManager.localeStrings.OK
> > >>
> > >> Besides the fact that I hate “magic”, this has the advantage of
> allowing
> > >> me to make localeStrings a typed class so I get type checking on the
> > actual
> > >> strings to prevent mistakes...
> > >>
> > >> HTH,
> > >> Harbs
> > >>
> > >>> On Jul 1, 2020, at 3:14 AM, Hugo Ferreira <hf...@gmail.com>
> > >> wrote:
> > >>>
> > >>> What's the recommended approach for localization in Royale ?
> > >>> An out of the box API that grabs a txt file with the key/values ?
> > >>
> > >>
> >
> >
>


-- 
Andrew Wetmore

http://cottage14.blogspot.com/

Re: Localization

[Hugo Ferreira <hf...@gmail.com>]

Very good.
I will follow the same approach.
Never liked the Flex way.

Harbs <ha...@gmail.com> escreveu no dia quarta, 1/07/2020 à(s) 10:49:

> I don’t actually propagate changes. In my case, all localization is
> determined at launch time. I have a RuntimeOptions class which gets runtime
> options from url parameters (using a ApplicationParametersCaseInsensitive
> bead). One of the runtime options in locale.
>
> Currently, I’m bundling all localized strings in the actual app. That adds
> a non-insignificant weight to the app, so someday, I’ll probably pull the
> strings out and load them as-needed.
>
> Either way, here’s the current full LocaleManager class:
> https://paste.apache.org/17dzh <https://paste.apache.org/17dzh>
>
> I have some cruft from old implementations and some which will hopefully
> be improved in the future, but you should get the idea.
>
> IUIStrings contains all the definitions.
>
> > On Jul 1, 2020, at 11:33 AM, Hugo Ferreira <hf...@gmail.com>
> wrote:
> >
> > "this has the advantage of allowing me to make localeStrings a typed
> class
> > so I get type checking on the actual strings to prevent mistakes"
> >
> > That's a very good idea !
> > I never liked the way that Flex deals with that and sometimes there are
> > type check errors that I can only see at runtime.
> >
> > Can you give an example, how the value changed (language value) in the
> > constant: LocaleManager.localeStrings.OK ?
> >
> > Harbs <ha...@gmail.com> escreveu no dia quarta, 1/07/2020 à(s)
> 07:32:
> >
> >> [ResourceBundle] has support, but I’m pretty sure that’s in mx. You can
> >> probably use it even if you’re not using mx components (I think).
> >>
> >> I’ve always used my own home-grown method of loading locale strings and
> >> construct them into an object which is read using keys.
> >>
> >> i.e. LocaleManager.localeStrings.OK
> >>
> >> Besides the fact that I hate “magic”, this has the advantage of allowing
> >> me to make localeStrings a typed class so I get type checking on the
> actual
> >> strings to prevent mistakes...
> >>
> >> HTH,
> >> Harbs
> >>
> >>> On Jul 1, 2020, at 3:14 AM, Hugo Ferreira <hf...@gmail.com>
> >> wrote:
> >>>
> >>> What's the recommended approach for localization in Royale ?
> >>> An out of the box API that grabs a txt file with the key/values ?
> >>
> >>
>
>

Re: Localization

[Harbs <ha...@gmail.com>]

I don’t actually propagate changes. In my case, all localization is determined at launch time. I have a RuntimeOptions class which gets runtime options from url parameters (using a ApplicationParametersCaseInsensitive bead). One of the runtime options in locale.

Currently, I’m bundling all localized strings in the actual app. That adds a non-insignificant weight to the app, so someday, I’ll probably pull the strings out and load them as-needed.

Either way, here’s the current full LocaleManager class: https://paste.apache.org/17dzh <https://paste.apache.org/17dzh>

I have some cruft from old implementations and some which will hopefully be improved in the future, but you should get the idea.

IUIStrings contains all the definitions.

> On Jul 1, 2020, at 11:33 AM, Hugo Ferreira <hf...@gmail.com> wrote:
> 
> "this has the advantage of allowing me to make localeStrings a typed class
> so I get type checking on the actual strings to prevent mistakes"
> 
> That's a very good idea !
> I never liked the way that Flex deals with that and sometimes there are
> type check errors that I can only see at runtime.
> 
> Can you give an example, how the value changed (language value) in the
> constant: LocaleManager.localeStrings.OK ?
> 
> Harbs <ha...@gmail.com> escreveu no dia quarta, 1/07/2020 à(s) 07:32:
> 
>> [ResourceBundle] has support, but I’m pretty sure that’s in mx. You can
>> probably use it even if you’re not using mx components (I think).
>> 
>> I’ve always used my own home-grown method of loading locale strings and
>> construct them into an object which is read using keys.
>> 
>> i.e. LocaleManager.localeStrings.OK
>> 
>> Besides the fact that I hate “magic”, this has the advantage of allowing
>> me to make localeStrings a typed class so I get type checking on the actual
>> strings to prevent mistakes...
>> 
>> HTH,
>> Harbs
>> 
>>> On Jul 1, 2020, at 3:14 AM, Hugo Ferreira <hf...@gmail.com>
>> wrote:
>>> 
>>> What's the recommended approach for localization in Royale ?
>>> An out of the box API that grabs a txt file with the key/values ?
>> 
>> 

Re: Localization

[Hugo Ferreira <hf...@gmail.com>]

"this has the advantage of allowing me to make localeStrings a typed class
so I get type checking on the actual strings to prevent mistakes"

That's a very good idea !
I never liked the way that Flex deals with that and sometimes there are
type check errors that I can only see at runtime.

Can you give an example, how the value changed (language value) in the
constant: LocaleManager.localeStrings.OK ?

Harbs <ha...@gmail.com> escreveu no dia quarta, 1/07/2020 à(s) 07:32:

> [ResourceBundle] has support, but I’m pretty sure that’s in mx. You can
> probably use it even if you’re not using mx components (I think).
>
> I’ve always used my own home-grown method of loading locale strings and
> construct them into an object which is read using keys.
>
> i.e. LocaleManager.localeStrings.OK
>
> Besides the fact that I hate “magic”, this has the advantage of allowing
> me to make localeStrings a typed class so I get type checking on the actual
> strings to prevent mistakes...
>
> HTH,
> Harbs
>
> > On Jul 1, 2020, at 3:14 AM, Hugo Ferreira <hf...@gmail.com>
> wrote:
> >
> > What's the recommended approach for localization in Royale ?
> > An out of the box API that grabs a txt file with the key/values ?
>
>

Re: Localization

[Harbs <ha...@gmail.com>]

[ResourceBundle] has support, but I’m pretty sure that’s in mx. You can probably use it even if you’re not using mx components (I think).

I’ve always used my own home-grown method of loading locale strings and construct them into an object which is read using keys.

i.e. LocaleManager.localeStrings.OK

Besides the fact that I hate “magic”, this has the advantage of allowing me to make localeStrings a typed class so I get type checking on the actual strings to prevent mistakes...

HTH,
Harbs

> On Jul 1, 2020, at 3:14 AM, Hugo Ferreira <hf...@gmail.com> wrote:
> 
> What's the recommended approach for localization in Royale ?
> An out of the box API that grabs a txt file with the key/values ?