[Sputnik-list] regarding internationalization

[Yuri Takhteyev]

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!)?