[Sputnik-list] regarding internationalization

[Dado Sutter]

Hello Everyone,
   I like the locale(MsgName) aproach, if it also leads to keep all the
locale messages grouped together in the same place.
   We're ready to work on the portuguese (brazilian) translation, once we
get the final word for the aproach from Yuri.

[]sssssssssss
Dado Sutter



On 6/26/07, Andre Carregal <carregal at fabricadigital.com.br> wrote:
>
> Well, I really don't think that string variables in templates are a
> bad thing per se. But yours are not strings, but tables of strings, so
> maybe you could think in a different syntax for them like @greetings
> instead of $greetings, or simply use a function call like
> locale(greetings).
>
> I still think that the "greetings" part should clearly be an
> identifier, not a string with even spaces.
>
> André
>
> On 6/26/07, Yuri Takhteyev <yuri at sims.berkeley.edu> wrote:
> > Since Greg asked a very similar question to Andre's yesterday
> > (especially the part about $var syntax), I will just forward my
> > response.
> >
> > Question:
> >
> > I am concerned that because your existing design co-mingles template
> > structure (html) and language strings, maintainability will become a
> > nightmare whenever a structural feature change is made (i.e. consider
> > preview; I had to make significant mods to Template:English)
> >
> > Since you are making an effort to internationalize it.. seems to me
> > sooner than later might be the time to think about breaking out the
> > templates into structure and language separately.  I'm sure an existing
> > cosmo use or a modification could easily be used to allow all the
> > language-dependent strings as $variables into the structure template.
> >
> > Answer:
> >
> > Well, it's way more separated than seems customary with gettext today.
> > Note that you can think of _(....) as just variables, the only
> > difference being that you can put spaces, etc.  in them.
> >
> > So, if you decide to change the English text in the preview, you do
> > not actually need to change the _(...) string.  E.g., you can keep
> > _(change) in the template and set
> >
> >     change = { "Edit again" }
> >
> > I did think of re-using cosmo variables, but this seemed to mean
> > mixing language strings with the code, which is even worse, isn't it?
> > Not mixing in the sense of having to hardcode it, but in the sense of
> > having "action" code that needs to know about translation strings.  We
> > can change the _(...) syntax, but what I wanted to do is keep
> > translation separated from filling in the data.  There are now two
> > steps:
> >
> > 1. When the template is loaded, we use the generic template +
> > translation table + language selection to get a localized template.
> > 2. The action fills _data_ into the localized table.
> >
> > The point is that i don't want the actions to ever have to know that
> > the template needed to be translated.
> >
> > The only problem I see with this approach myself is that I now have
> > cosmo $variables in the translation file.  This does bother me
> > somewhat.  But any other approach that I tried ended up being messier.
> >
> > Perhaps I didn't understand your question.  Would it make more sense
> > to you if all string placeholders were named something like
> > _(USER_GREETING) instead of _(Hi user!)?
> >
> > _______________________________________________
> > Sputnik-list mailing list
> > Sputnik-list at lists.luaforge.net
> > http://lists.luaforge.net/cgi-bin/mailman/listinfo/sputnik-list
> >
> >
>
> _______________________________________________
> Sputnik-list mailing list
> Sputnik-list at lists.luaforge.net
> http://lists.luaforge.net/cgi-bin/mailman/listinfo/sputnik-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.luaforge.net/pipermail/sputnik-list/attachments/20070626/5c9f1216/attachment.html