[Sputnik-list] regarding internationalization

[Andre Carregal]

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
>
>