Re: [help-texinfo] Re: Setting human languag for makeinfo
Torsten Bronger <[email protected]> Sun, 10 Apr 2005 22:59:22 +0200
| Newsgroups | gmane.comp.tex.texinfo.pretest |
|---|---|
| Organization | Phoenix Foundation |
| Message-ID | <[email protected]> |
Hall=C3=B6chen! [email protected] (Karl Berry) writes: > [...] > > we now know how unreliable it seems to be. =20 > > For Texinfo's purposes, we can simply document the combinations > that work. (Except nothing is working for me, but hopefully > that's fixable :) Unless proven wrong, I assume that the de_DE form always works, as claimed in the link I provided. > Well, it's misusing setlocale() after all. > > I'm not sure I buy "misuse". Well, misuse is often in the eye of the beholder. I think it is misuse because the locale should be set by the user. I googled a lot and found pretty little about setting it to an arbitrary language from program code. While the locale system on a particular computer is consistent, it's difficult to make any assumptions on it from outside. So, the user's setting will work, and he can reset it successfully, too, but reliable setting without thorough examination of the remote system is problematic. Locales haven't been made for this. > What alternative is there? The only secure alternative -- as far as I can see -- is infrastructure parallel to gettext. However, I get more and more confident in the setlocale-gettext hack. The only clean alternative would be another gettext() variant with a language code as the second argument and a useful fallback mechanism. > [...] > > Anyway, here is the message from Bruno that I was thinking of, with his > locale-switching function -- basically takes care of a bunch of other > envvars, too: > http://lists.gnu.org/archive/html/bug-texinfo/2003-12/msg00023.html Interesting. Unfortunately, the critical thing, namely the determination of the foreign locale code, is not demonstrated there, since the destination locale is taken from a command line option as far as I can see. > It occurs to me now that getdoctext or gettextdoc or docgettext > might be a clearer name than doclang_. Or maybe simply _doc. > Hmm. I can't say something about this. You decide, I'm flexible. :-) > My other comment is that I think @documentlanguage actually should > support LL_CC as well as just LL, so that if someone wants to > write a Texinfo document in Austrian German, they can. While it's easy to deal with this possibility, I'm again concerned about setlocale()'s behaviour: If de_AT doesn't exist (e.g. too old Texinfo version or not yet supported at all), setlocale() would switch to English rather than to de_DE (as it does for fr_RR). However, I have to check that. > [...] I don't know the dialect specification rules for HTML, which > is where language_code gets used, as I recall. HTML uses de, de-DE, de-AT etc. By the way, I myself registered de-DE-1901, de-DE-1996 etc with IANA a couple of years ago, due to the German orthography reform. They are really useful since babel supports german, austrian, ngerman, and naustrian. You see, language is an awfully complex subject. :) But seriously: Maybe it's best to use the HTML (=3DXML) notation for @documentlanguage. It's the best maintained in my opinion, and not very different. > Oh, and I wonder if it would be better to add the new information to > language_table in lang.c, instead of creating still another big table .= .. > (Not sure.) I'll have a look at it. Tsch=C3=B6, Torsten. P.S.: I realised two weeks ago that a certain KH Marbaise was responsible for the initial language support. We live in the same 250000 souls town and meet every other month. Sometimes the world is a very small place ... --=20 Torsten Bronger, aquisgrana, europa vetus _______________________________________________ Texinfo home page: http://www.gnu.org/software/texinfo/ [email protected] http://ff0.org/mailman/listinfo/texinfo-pretest