Ideal D GUI Toolkit

[Peter Williams]

On 23/05/13 11:23, Adam D. Ruppe wrote:
> I've never actually done i18n so I might be full of crap, but I think a
> nice way to do it would be something along these lines:
>
> 1) (optionally) all printing functions actually take a different type
> than just plain string, forcing you to use the translation function

Not all strings should be translated.  So you need a way to say which 
ones do need to be translated.  Many schemes have been invented over the 
years (by Sun, Microsoft, etc.) but most of them died when gettext() 
came along as they were all very complex compared to gettext() and 
usually involved creating digests and giving strings id numbers etc. 
which rapidly became a maintenance nightmare.

The key simplicity of gettext() is the each string is its own identifier 
and notification that a string needs translating and doing the 
translation call is the one piece of code.

There is a minor complication with using strings declared as variables 
in COMPILED languages as the translation can't be done at compile time 
so they have two notations:

1. what I described above it gettext('string') means mark 'string' for 
translation and also return me the translation of 'string' i.e. a 
compile time meaning and a runtime meaning
2. a second template gettext_noop('string') which just means mark the 
string for translation and that's all.  In C and C++ this is usually 
just a macro that does nothing.  Then when you need the string variable 
later on you use gettext(<variable name>) to get the translation.  NB 
down in the guts it's just the contents of the string that is used as 
the key in the translation mechanism and there's no need to track the 
fact that it contains a translatable string.  Gettext() never fails and 
if it's called with a string that it cant find the translation for it 
just returns its argument unchanged.  In D, I imagine the best way to do 
this would be to have some sort of qualifier that could be used as part 
of the string variable declaration to tag it as a target for translation.

One of the things that is useful when doing i18n is having writef, etc. 
have the ability to specify which arguments should be placed where in 
the format string as it sometimes necessary to reorder them in order to 
make a translation that makes sense in the target language (as not all 
languages have a subject-verb-object grammar e.g. Yoda).

An example of how I would envisage gettext being used in D is:

writefln(gettext("%s: unknown variable at line %s"), filename, linenumber);

It is a common practice, to define a macro (or equivalent) _(arg) as an 
alias for gettext(arg) (and N_(arg) for gettext_noop(arg)) because 
people like brevity.

I would suggest using the gettext() functionality for i18n but design 
the notation used within programs (to access that functionality) 
according to what best suits the D paradigm.

Peter