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.
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?
> 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.
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!
> 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 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?
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 :
> > 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!
