I started a to work on a localization support for Aida.
It's available at: http://mc.bioskop.fr/AidaLocalization
It's quite simple for now: AIDASite has a #preferedLanguage accessor
which return a symbol (by default #en), and has a translator, an
instance of AIDATranslator.
A translator knows how to translate a sentence:
(AIDASite named: 'aidademo') translator addTranslation:
('Hello'->'Bonjour') language: #fr
then
(AIDASite named: 'aidademo') translator translate: 'Hello' to: #fr
>>>'Bonjour'
in views we can translate a sentence with:
self translate: aString
for example:
#viewMain
| e |
e := WebElement new.
self title: (self translate: 'Hello').
e addTextH1: self title.
self pageFrameWith: e title: self title
if the corresponding translation is not found, the string is just
returned.
Finally, we can change the language of a site with:
(AIDASite named: 'aidademo') preferedLanguage: #fr
And all translations are stored in a dictionary in a class variable, so
each translator (one per site) knows all available translations.
It's already working, but could certainly be improved.
Cheers!
Nico
--
Nicolas Petton
http://nico.bioskop.fr
___
ooooooo
OOOOOOOOO
|Smalltalk|
OOOOOOOOO
ooooooo
\ /
[|]
--------------------------------
Ma clé PGP est disponible ici :
http://nico.bioskop.fr/pgp-key.html
I'm thinking about localization for a long time, that is, how to do it
as simply as possible, otherwise we will soon "degrade" back to putting
texts directly to the code as it is the case now.
My proposal in few words:
1. use symbols instead of string for any text, for example:
a addText: #welcome instead of a addText: 'Welcome'
2. store language mappings for each view of each App and not globally
for a whole site
3. in-line editing (in admin mode) of such text for each view to make
translation in different languages. This will be as simple as
possible for translators to make such translation.
4. also a traditional edit table of texts and translations, but again
per view per App
I think this way we can make localization of page texts really simple
and user friendly, both for us programmers and end users.
Nico, I tried your proposal many years ago (see WebMsgs, the remains of
that try) and it didn't work. First reason is that is too hard to
program - to enter a text on pages, another is that WebMsgs was a global
(site) catalog and it soon expanded and become hard to maintain. Another
problem is where to store such catalogs. Maybe in methods too, as we are
doing with method images?
Best regards
JAnko
--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
Aida mailing list
Ai...@aidaweb.si
http://lists.aidaweb.si/mailman/listinfo/aida
> 3. in-line editing (in admin mode) of such text for each view to make
> translation in different languages. This will be as simple as
> possible for translators to make such translation.
Let me explain this idea a bit further. Idea is to edit text directly on
a page (but also separately in some special view). Ok, this special view
is a standard table of all texts and their translations. But such table
is optional while main means to edit text is directly on the page. That
is, you simply click the text and edit it directly on its position of
the page.
Main advantage of in-line editing/translating is that you better see the
context of each text among other on the page. This leads to better and
more exact translations.
Achieving such editing may be technically challenging but it is worth
effort, that's I'm sure!
Janko
What I thought about for localization (for UIs) was to use strings, but
allow for scoping.
Just as an idea:
'#fr.#appContext.the string to translate with %arg1' printf: {123. }
and then look up the translation by original language (fr) and context
(appContext). The extra (optional?) language parameter would allow to
have the original strings in languages other then English.
I generally don't like to have any data in methods, be it images or
translation dictionaries. Doubles the needed space and bloats source
code repositories.
Michael
>> 1. use symbols instead of string for any text, for example:
>> a addText: #welcome instead of a addText: 'Welcome'
>> 2. store language mappings for each view of each App and not globally
>> for a whole site
>
> What I thought about for localization (for UIs) was to use strings, but
> allow for scoping.
> Just as an idea:
>
> '#fr.#appContext.the string to translate with %arg1' printf: {123. }
>
> and then look up the translation by original language (fr) and context
> (appContext). The extra (optional?) language parameter would allow to
> have the original strings in languages other then English.
>
> I generally don't like to have any data in methods, be it images or
> translation dictionaries. Doubles the needed space and bloats source
> code repositories.
Michael, can you provide an example how would you do that in Smalltalk
or Aida case?
Janko
--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
I see a limit to your idea:
How do you translate strings coming from the style (navigation bar,
etc)? You'll have to duplicate translations for each view of each app?
nico