headers
Nicolas Petton | 11 May 16:43
Picon

Aida-Localization

Hi all,

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.
(Continue reading)

Permalink | Reply |
headers
Janko Mivšek | 11 May 17:32
Picon

Re: Aida-Localization

Hi Nico,

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
(Continue reading)

Permalink | Reply |
headers
Janko Mivšek | 11 May 17:41
Picon

Re: Aida-Localization

Janko Mivšek wrote:

>   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

--

-- 
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
Aida mailing list
Aida <at> aidaweb.si
(Continue reading)

Permalink | Reply |
headers
Nicolas Petton | 11 May 20:45
Picon

Re: Aida-Localization

Janko,

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

Le dimanche 11 mai 2008 à 17:41 +0200, Janko Mivšek a écrit :
> Janko Mivšek wrote:
> 
> >   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
(Continue reading)

Permalink | Reply |
headers
Michael Rueger | 11 May 19:28
Picon
Favicon

Re: Aida-Localization

Janko Mivšek wrote:
> Hi Nico,
> 
> 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

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
_______________________________________________
(Continue reading)

Permalink | Reply |
headers
Janko Mivšek | 11 May 19:35
Picon

Re: Aida-Localization

Michael Rueger wrote:

>>   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
(Continue reading)

Permalink | Reply |

Gmane