Re: i18n

Alex Russell <[email protected]>
Newsgroups gmane.comp.windows.devel.netwindows
Organization netWindows.org
Message-ID <[email protected]>
On Thursday 04 September 2003 16:54, Christian Boulanger wrote:
> I have to correct myself. The proposed method of course doesn't work ... If
> the undescored string has been translated once, it cannot be retranslated
> into the underscore string (duh!)!
> Instead, I what about markup? Something like
>
> <span  i18n_lang="de" i18n_key="enter_password">Bitte Passwort
> eingeben</span>
>
> The server-side language could then translate underscore strings into this
> syntax (initial server-side translation), and the client can use the markup
> to do client-side translation.

That's actually kind of funny. I wrote a ~10K draft email yesterday explaining 
why I thought that a synthetic key for translation was necessaray and how 
submitting nodes (and not keys) for translation would be problematic. Nice to 
see we got to the same place without all the back and forth = )

> Maybe you already have thought of something more elegant...

Nope. This is essentially the same thing that gettext does under the covers, 
and I think that something like a __data__ transaction to get the translated 
string (or better, a whole dict of them which can be kept in memory) is a 
good way to implement this.

Any other thoughts around this? I know bi-di and declared page character 
encoding will bite us sooner or later, so if there are any non-romance 
language speakers on the list that have thoughts on how they've dealt with 
this I'd be interested to hear them.

Regards

-- 
Alex Russell
[email protected]    BD10 7AFC 87F6 63F9 1691 83FA 9884 3A15 AFC9 61B7
[email protected]  F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46

_______________________________________________
The netWindows developers list: [email protected]
http://netwindows.org/mailman/listinfo/devel_netwindows.org
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.