which i18n function to use?

Christian Stimming stimming@tuhh.de
Sun, 1 Apr 2001 16:44:02 -0700


-----BEGIN PGP SIGNED MESSAGE-----

For the record. My suggestion won't work, and the help strings in options 
should still be translated with N_ .

On Sunday 01 April 2001 14:58, Dave Peticolas wrote:
> Christian Stimming writes:
> > I would
> > request to change the way it's done right now. Instead I would like to
> > suggest we restrict the usage of N_ to the cases if and only if
> > strings are used as keys, and to use _ in *all* other cases.
>
> That's fine.

<dave_p> actually, that reminds me of a reason not to use _ in option help 
- -- the display code runs it through gettext already.
<cstim> you mean, it would run the translated string through gettext?
<dave_p> right
<cstim> this doesn't sound like a good thing to do...
<dave_p> the risk is that a translation is also an english word which has 
yet another translation. a small risk, but still possible.
<cstim> exactly
<cstim> so which code does that? Options. Tip-of-day. What else? Or is 
there a general rule?
<dave_p> well, the rule I try to follow is the code that prepares the 
string for display is the one that actually does the translation. so 
options strings use N_, but html code uses _.
<cstim> okay... not very elegant, though. That rule is rather blurry.
<dave_p> well, it's a blurry situation :) there are other factors than 'is 
it a key'? for example N_ will be faster to load than _ so it makes sense 
to use it in tip-list.scm and only translate them when you need them. 
also, just because something isn't being used as a key *now* doesn't mean 
we might not want to in the future.
<cstim> sigh
<dave_p> anyway, the html rendering functions don't do any translation. 
there's no way they could distignuish between what needs to be what 
doesn't.
<cstim> yeah, right.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)

iQCVAwUBOse9Q2XAi+BfhivFAQGFTAP+NXjTVG8cBbs2Cn5JoRgHQocdIGurm2OW
4WqGIBN+b+0h7zrXsIgVnybRb8hKKauPgJ0Wh535O4fyQy3ppFklT7qbaO1U4abz
KOCgh/BEkv/u9z5atKACYpQzJyi8gaUWDanT7Zb1NFoQBRxzol367SmyjsbBrfo3
E1xRjTUoRjc=
=VgaK
-----END PGP SIGNATURE-----