tag:old.nabble.com,2006:forum-1827Nabble - Gnu - Utils2009-11-28T20:44:07ZGnu - Utils home is <a href="http://www.gnu.org/software/" target="_top" rel="nofollow">here</a>.tag:old.nabble.com,2006:post-26559340Re: German uppercasing rules (was: supporting obscure languages)2009-11-28T20:44:07Z2009-11-28T20:44:07ZJohn CowanAlbert Cahalan scripsit:
<br><br>> > Unicode 5.0 has introduced the character U+1E9E "LATIN CAPITAL LETTER SHARP S",
<br>> > but the habits in Germany have not changed. The upper-case variant of "Ruß"
<br>> > is still "RUSS". German people don't care about whether this round-trips
<br>> > or not. "ß" uppercases to "SS". It has been like this for centuries.
<br>>
<br>> Germans with "ß" in their last name are people too, and they care.
<br><br>I don't see why those people would expect to see their names in upper case.
<br><br>> U+1E9E exists solely because there is real evidence that people care.
<br><br>True, but the people in question are mostly the designers of
<br>advertisements who want to put headlines in all caps.
<br><br>As a certified alter kocker, I personally think that German looks horrible
<br>in all caps, but that battle was lost a generation ago.
<br><br>> It is pretty common to uppercase "ß" as itself; clearly people care.
<br><br>Especially if they have blindly applied simple Unicode uppercasing rather
<br>than proper German uppercasing.
<br><br>Turkic, though, is a more complex problem. Knowing how to properly recase
<br>German or Greek just requires applying the algorithm: you don't have to
<br>know that the text actually is German or Greek. To correctly change the
<br>case of a Turkic language, you have to know for sure that you are dealing
<br>with Turkic text. I can well understand if people fail to get that right,
<br><br>--
<br>John Cowan <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26559340&i=0" target="_top" rel="nofollow">cowan@...</a> <a href="http://www.ccil.org/~cowan" target="_top" rel="nofollow">http://www.ccil.org/~cowan</a><br> Is it not written, "That which is written, is written"?
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26557718Re: German uppercasing rules (was: supporting obscure languages)2009-11-28T14:51:18Z2009-11-28T14:51:18ZBruno HaibleAlbert Cahalan wrote:
<br>> Sooner or later, a <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26557718&i=0" target="_top" rel="nofollow">de_DE@...</a> locale will be demanded.
<br><br>Yes, certainly. Maybe in 5 years, or 10 years, or in 20 years. But currently,
<br>hardly any font contains the U+1E9E "LATIN CAPITAL LETTER SHARP S" character.
<br>Therefore currently, we should stay with the traditional rule of "ß" -> "SS".
<br><br>> In any case, you won't be getting "SS" out of towupper.
<br><br>Yes. It is for this reason that
<br> 1. towupper('ß') == 'ß',
<br> 2. a simple loop that calls towupper is *not* the right way to uppercase an
<br> arbitrary string.
<br><br>And lowercasing does not work with a simple loop over towlower either, because
<br>of GREEK CAPITAL LETTER SIGMA that needs special treatment.
<br><br>> I hope libunistring doesn't impede the evolution of languages.
<br><br>libunistring is free software: it can be changed to fit particular needs.
<br><br>Bruno
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26558653Re: German uppercasing rules (was: supporting obscure languages)2009-11-28T13:36:39Z2009-11-28T13:36:39ZAlbert CahalanOn Sat, Nov 28, 2009 at 3:11 PM, Bruno Haible <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26558653&i=0" target="_top" rel="nofollow">bruno@...</a>> wrote:
<br>> Albert Cahalan wrote:
<br><br>>> Maybe round-trip the case for U+1E9E, avoiding expansion troubles.
<br>>
<br>> Unicode 5.0 has introduced the character U+1E9E "LATIN CAPITAL LETTER SHARP S",
<br>> but the habits in Germany have not changed. The upper-case variant of "Ruß"
<br>> is still "RUSS". German people don't care about whether this round-trips
<br>> or not. "ß" uppercases to "SS". It has been like this for centuries.
<br><br>Germans with "ß" in their last name are people too, and they care.
<br>U+1E9E exists solely because there is real evidence that people care.
<br>It is pretty common to uppercase "ß" as itself; clearly people care.
<br><br>Sooner or later, a <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26558653&i=1" target="_top" rel="nofollow">de_DE@...</a> locale will be demanded.
<br>German rules have changed a number of times in the 1900s, and
<br>they certainly can change again.
<br><br>In any case, you won't be getting "SS" out of towupper.
<br><br>> Therefore if you want your program to do case conversions right for German
<br>> (and Turkish, Greek, Lithuanian etc.), you need to perform case conversions
<br>> on entire strings, not merely on characters one by one. In C programs,
<br>> you can use GNU libunistring [1] for this purpose. It has all the special cases
<br>> built-in.
<br><br>Yes, of course, but that doesn't work for towupper.
<br><br>I hope libunistring doesn't impede the evolution of languages.
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26556553Re: German uppercasing rules (was: supporting obscure languages)2009-11-28T12:11:25Z2009-11-28T12:11:25ZBruno HaibleAlbert Cahalan wrote:
<br>> Maybe round-trip the case for U+1E9E, avoiding expansion troubles.
<br><br>Unicode 5.0 has introduced the character U+1E9E "LATIN CAPITAL LETTER SHARP S",
<br>but the habits in Germany have not changed. The upper-case variant of "Ruß"
<br>is still "RUSS". German people don't care about whether this round-trips
<br>or not. "ß" uppercases to "SS". It has been like this for centuries.
<br><br>Therefore if you want your program to do case conversions right for German
<br>(and Turkish, Greek, Lithuanian etc.), you need to perform case conversions
<br>on entire strings, not merely on characters one by one. In C programs,
<br>you can use GNU libunistring [1] for this purpose. It has all the special cases
<br>built-in.
<br><br>Bruno
<br><br>[1] <a href="http://www.gnu.org/software/libunistring/" target="_top" rel="nofollow">http://www.gnu.org/software/libunistring/</a><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26556773Re: supporting obscure languages2009-11-28T11:53:26Z2009-11-28T11:53:26ZAlbert CahalanOn Sat, Nov 28, 2009 at 10:49 AM, Bruno Haible <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26556773&i=0" target="_top" rel="nofollow">bruno@...</a>> wrote:
<br><br>> It is similar to LC_MESSAGES=zam_MX.UTF-8 LANG=fr_FR.UTF-8, which would
<br>> be a perfectly reasonable choice for a user with French preferences but
<br>> Zapotec language. POSIX allows users to combines different aspects of
<br>> locales in this way.
<br><br>POSIX does, but the library does not. If the library followed POSIX
<br>then I could combine LC_MESSAGES=zam with LANG=C.
<br><br>In other words, this looks like a POSIX violation to me.
<br><br>> It is gross, but it is consequence of your desire to use a language
<br>> for which the locale is not existent or not installed, and therefore
<br>> to do in your program what normally the users do in their system. This is
<br>> not typical. The normal case is that users set their preferences in a
<br>> central location and these preferences get transmitted to the programs via
<br>> environment variables.
<br><br>The only part I need is installed: zam.mo
<br><br>Since I never try to format time, the library shouldn't even try
<br>to load the data for that. The missing stuff shouldn't affect
<br>anything since I'm not attempting to use it. Supposing I did
<br>try to format time though, that could do some typical thing.
<br><br>Basically this isn't fail-safe. Some chunk of locale data goes
<br>missing, and suddenly the whole thing dies.
<br><br>>> I'm depending on some random unrelated locale
<br>>> just to get normal UTF-8 behavior.
<br>>
<br>> Yes, this is worrying. But nowadays, on most desktop systems, at least
<br>> one user locale is installed, it uses UTF-8 encoding, and you can
<br>> enquire it through setlocale(LC_ALL,"").
<br>>
<br>> The systems with only the "C" locale are small-memory devices like
<br>> routers.
<br><br>That was my system until I started debugging this problem,
<br>and in fact an apt-get hook wipes out locales every time I
<br>install packages.
<br><br>This is because en_US.UTF-8 has defective collation order,
<br>and because I don't normally need translations. If I were to
<br>set either LANGUAGE or LC_MESSAGES alone though,
<br>that ought to get me translations despite anything else.
<br><br>> Internationalization of a program consists of three parts:
<br>> 1) Make use of the Unicode character set.
<br>> 2) Provide translations for messages.
<br>> 3) Do the following in a locale dependent way: display of time,
<br>> display of currency, computations with calendar, display of
<br>> Hanzi ideographs (Chinese vs. Japanese - same Unicode code
<br>> point, different glyphs), form for entering a postal address,
<br>> arrangement of GUI components (right-to-left), etc.
<br><br>Well no, not unless the program needs it. OTOH, Tux Paint
<br>localizes things you don't even handle: audio clips, fonts,
<br>font size, font vertical position, and right-to-left text rendering.
<br><br>In any case, part of a locale is better than none. Right now
<br>you're essentially saying that incomplete localization isn't
<br>allowed; it's all or nothing.
<br><br>> With a "C" locale in UTF-8 encoding, you would get part 1). You would
<br>> not get part 2), because gettext() must not use the translation message
<br>> catalogs in the "C" locale. You would also not get part 3), because
<br>> strftime etc. also must not use localized values in the "C" locale.
<br>> That's because in POSIX, the "C" locale is the locale to be set when you
<br>> want to know ahead of time the output format of "ls", "df", "date" etc.
<br><br>Ah, but I asked for a different locale.
<br><br>LANGUAGE: not set to "C"
<br>LC_ALL: not set to "C"
<br>LC_MESSAGES: not set to "C"
<br>LANG: not set to "C"
<br>setlocale's 2nd parameter: not set to "C"
<br><br>That right there means I didn't want the "C" locale. Additionally,
<br>at least one of those things is not blank/empty/missing, so you
<br>certainly know which locale I want. I expect best-effort.
<br>I even called bind_textdomain_codeset, so UTF-8 is explicit.
<br><br>Had I set nothing, I still wouldn't be asking for "C". You could
<br>give me a "generic.UTF-8" or "NULL.UTF-8" locale that works.
<br><br>BTW, even the strings being passed to gettext() are UTF-8.
<br>I have things like the elipsis, so it's still UTF-8 even when the
<br>translation is dumped on the floor.
<br><br>> But I agree with you that it would be useful if more Linux distributors
<br>> would install an en_US.UTF-8 locale always.
<br><br>Debian seems to have chosen to add C.UTF-8. From my reading of
<br>the code, it looks like that will fail. They'll patch it I'm sure.
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26554260Re: supporting obscure languages2009-11-28T07:49:03Z2009-11-28T07:49:03ZBruno HaibleHello Albert,
<br><br>> >> All I care about: LC_MESSAGES for "zam", LC_CTYPE not lobotomized
<br>> >
<br>> > Then your workaround of doing
<br>> > LANGUAGE=zam LC_ALL=fr_FR.UTF-8
<br>> > is just fine.
<br>>
<br>> Don't you think that is terribly gross? (French with
<br>> different words!)
<br><br>It is similar to LC_MESSAGES=zam_MX.UTF-8 LANG=fr_FR.UTF-8, which would
<br>be a perfectly reasonable choice for a user with French preferences but
<br>Zapotec language. POSIX allows users to combines different aspects of
<br>locales in this way.
<br><br>> Don't you think it's doubly gross to have a program
<br>> calling setenv() to control a library via environment
<br>> variables intended for users instead of a proper API?
<br>> ... setenv as an API
<br>> is really disturbing. I greatly prefer to treat the environment
<br>> as read-only.
<br><br>It is gross, but it is consequence of your desire to use a language
<br>for which the locale is not existent or not installed, and therefore
<br>to do in your program what normally the users do in their system. This is
<br>not typical. The normal case is that users set their preferences in a
<br>central location and these preferences get transmitted to the programs via
<br>environment variables.
<br><br>> The library doesn't even get immediate notice that there
<br>> has been a change unless you have evil hooks into the
<br>> setenv and getenv functions.
<br><br>You don't have such hooks in the setlocale function either. Sadly.
<br><br>> I'm depending on some random unrelated locale
<br>> just to get normal UTF-8 behavior.
<br><br>Yes, this is worrying. But nowadays, on most desktop systems, at least
<br>one user locale is installed, it uses UTF-8 encoding, and you can
<br>enquire it through setlocale(LC_ALL,"").
<br><br>The systems with only the "C" locale are small-memory devices like
<br>routers.
<br><br>> > No, when you call setlocale(LC_ALL,"") it uses the locale that the
<br>> > user has set, not "C".
<br>>
<br>> I mean when the user has done nothing either. The "" doesn't
<br>> get filled in by some environment variable. You make it all the
<br>> way to the lowest-priority environment variable ("LANG") and
<br>> still have "". At that point, the implementation-specific locale
<br>> is chosen... and it is "C".
<br><br>If you are in this case, you are either on a misconfigured desktop
<br>system, or on a small-memory system on which your program is likely
<br>not meant to run.
<br><br>> Basically: use what is there, and assume something close
<br>> to "C.UTF-8" for anything missing/broken. Maybe you could
<br>> find choices that are more generic than "C", like 24-hour time
<br>> and PA4 paper size. Maybe round-trip the case for U+1E9E,
<br>> avoiding expansion troubles. You could call it "default.UTF-8".
<br>>
<br>> The details aren't terribly critical; the main thing is to let a
<br>> random loose UTF-8 *.mo file work without hacks or fuss,
<br>> along with the wchar_t functions working beyond ASCII.
<br><br>Internationalization of a program consists of three parts:
<br> 1) Make use of the Unicode character set.
<br> 2) Provide translations for messages.
<br> 3) Do the following in a locale dependent way: display of time,
<br> display of currency, computations with calendar, display of
<br> Hanzi ideographs (Chinese vs. Japanese - same Unicode code
<br> point, different glyphs), form for entering a postal address,
<br> arrangement of GUI components (right-to-left), etc.
<br><br>With a "C" locale in UTF-8 encoding, you would get part 1). You would
<br>not get part 2), because gettext() must not use the translation message
<br>catalogs in the "C" locale. You would also not get part 3), because
<br>strftime etc. also must not use localized values in the "C" locale.
<br>That's because in POSIX, the "C" locale is the locale to be set when you
<br>want to know ahead of time the output format of "ls", "df", "date" etc.
<br><br>Conclusion: In general, a program cannot be internationalized if it
<br>relies on the "C" locale.
<br><br>Therefore only few program would profit from a "C" locale in UTF-8
<br>encoding.
<br><br>But I agree with you that it would be useful if more Linux distributors
<br>would install an en_US.UTF-8 locale always.
<br><br>Bruno
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26553268Re: supporting obscure languages2009-11-28T05:47:21Z2009-11-28T05:47:21ZBruno HaibleEric Blake wrote:
<br>> >> b. The "C" locale is not UTF-8. (this need not be the case)
<br>> >
<br>> > The "C" locale was defined at a time when there was no UTF-8. This
<br>> > choice accommodates for output devices that cannot display arbitrary
<br>> > Unicode characters (think of ssh into an older Unix system).
<br>>
<br>> But POSIX explicitly allows the "C" locale to use UTF-8, and in fact, that
<br>> is the case on cygwin 1.7.
<br><br>True. It's an implementation choice whether the "C" locale is in US-ASCII or
<br>UTF-8. In glibc, you would only have to change 1 file: glibc/locale/C-ctype.c.
<br>Or you can create a C.UTF-8 locale for yourself, using 'localedef'.
<br><br>But it would not help Albert's problem: When the LC_MESSAGES locale is "C",
<br>translations are disabled, regardless of the LANGUAGE environment variable.
<br>This is required for POSIX compatibility of tools (such as "cp" or "tar")
<br>which use gettext() for their internationalization.
<br><br>Bruno
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26553045Re: supporting obscure languages2009-11-28T05:14:09Z2009-11-28T05:14:09ZEric Blake-----BEGIN PGP SIGNED MESSAGE-----
<br>Hash: SHA1
<br><br>According to Bruno Haible on 11/28/2009 3:34 AM:
<br>>> b. The "C" locale is not UTF-8. (this need not be the case)
<br>>
<br>> The "C" locale was defined at a time when there was no UTF-8. This
<br>> choice accommodates for output devices that cannot display arbitrary
<br>> Unicode characters (think of ssh into an older Unix system).
<br><br>But POSIX explicitly allows the "C" locale to use UTF-8, and in fact, that
<br>is the case on cygwin 1.7. Per POSIX, the "C" locale is only portable for
<br>character operations for bytes < 128.
<br><br>- --
<br>Don't work too hard, make some time for fun as well!
<br><br>Eric Blake <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26553045&i=0" target="_top" rel="nofollow">ebb9@...</a>
<br>-----BEGIN PGP SIGNATURE-----
<br>Version: GnuPG v1.4.9 (Cygwin)
<br>Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
<br>Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/" target="_top" rel="nofollow">http://enigmail.mozdev.org/</a><br><br>iEYEARECAAYFAksRIiEACgkQ84KuGfSFAYAyPQCdHbfP/UQ57rkWeqVRLrwpN/PN
<br>xEYAn1pkhQtHYFYA0yUGRgvha9EDhOca
<br>=sAbk
<br>-----END PGP SIGNATURE-----
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26554432Re: supporting obscure languages2009-11-28T05:02:40Z2009-11-28T05:02:40ZAlbert CahalanOn Sat, Nov 28, 2009 at 5:34 AM, Bruno Haible <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26554432&i=0" target="_top" rel="nofollow">bruno@...</a>> wrote:
<br>> Albert Cahalan wrote:
<br><br>>> I don't need month name, time display rules, telephone formats...
<br>>>
<br>>> All I care about: LC_MESSAGES for "zam", LC_CTYPE not lobotomized
<br>>
<br>> Then your workaround of doing
<br>> LANGUAGE=zam LC_ALL=fr_FR.UTF-8
<br>> is just fine.
<br><br>Don't you think that is terribly gross? (French with
<br>different words!)
<br><br>Don't you think it's doubly gross to have a program
<br>calling setenv() to control a library via environment
<br>variables intended for users instead of a proper API?
<br><br>>> BTW, we'd like fallback to similar translations in case something
<br>>> is missing. When zh_TW.mo lacks something, zh_CN.mo should be the
<br>>> next place to look.
<br>>
<br>> That's a built-in feature in GNU gettext: just set the LANGUAGE variable to
<br>> zh_TW:zh_CN
<br>> and you're done.
<br><br>I guess we'll probably do that. Still, setenv as an API
<br>is really disturbing. I greatly prefer to treat the environment
<br>as read-only.
<br><br>The library doesn't even get immediate notice that there
<br>has been a change unless you have evil hooks into the
<br>setenv and getenv functions. You'd have to either do a
<br>slow getenv each time, or cache the value and hope the
<br>program doesn't try to change things later.
<br><br>>> setlocale(LC_ALL, loc); // loc="" or loc="zam"
<br>>> ctype_utf8(); // setlocale(LC_CTYPE,x) for many x until iswprint works
<br>>
<br>> Yes, you have no guarantee that a particular locale is installed on the user's
<br>> system. You have to try some. setlocale(LC_ALL, "") is a good first guess.
<br><br>That guess is just "C" on my system.
<br><br>>> My current hack: LANGUAGE=zam LC_ALL=fr_FR.UTF-8
<br>>>
<br>>> Yep, I'm telling gettext that this is French. That's disgusting.
<br>>
<br>> No, you are telling the system to use an UTF-8 encoding for strings,
<br>> French rules for time, sorting, numbers etc, and Zapotec for messages.
<br>> If it fits well with your program, all fine.
<br><br>Eh, the Zapotec dialect of French. It does work, as long as
<br>the user happens to have fr_FR.UTF-8 installed.
<br><br>That's trouble. I'm depending on some random unrelated locale
<br>just to get normal UTF-8 behavior.
<br><br>>> There are quite a few design bugs here, none of which would cause
<br>>> huge problems all by itself. Together, they are a disaster.
<br>>>
<br>>> a. The implementation-specific "" locale is "C". (it need not be)
<br>>
<br>> No, when you call setlocale(LC_ALL,"") it uses the locale that the
<br>> user has set, not "C".
<br><br>I mean when the user has done nothing either. The "" doesn't
<br>get filled in by some environment variable. You make it all the
<br>way to the lowest-priority environment variable ("LANG") and
<br>still have "". At that point, the implementation-specific locale
<br>is chosen... and it is "C".
<br><br>>> b. The "C" locale is not UTF-8. (this need not be the case)
<br>>
<br>> The "C" locale was defined at a time when there was no UTF-8. This
<br>> choice accommodates for output devices that cannot display arbitrary
<br>> Unicode characters (think of ssh into an older Unix system).
<br><br>I can sort of understand this. I own a real VT510 terminal.
<br><br>It's not a working protection though. Linux distributions often
<br>set a UTF-8 locale, then fail to translate or otherwise protect
<br>logins on the serial tty devices. This happens to be why procps
<br>replaces UTF-8 characters containing the 0x9b byte. (but of
<br>course that is potentially hostile data, not translations, and
<br>Red Hat patches out the protection anyway)
<br><br>Having "C" not be i18n-friendly (serving up UTF-8 messages
<br>and full Unicode on wchar_t) wouldn't be a big deal except
<br>for the fact that the locale so easily ends up being "C".
<br>(when unspecified, when a locale is broken/unknown, etc.)
<br><br>>> c. The "C" locale makes iswprint((wchar_t)0xf7) be false. (very bad)
<br>>
<br>> I agree with you that wide characters are a mess in ISO C, because the
<br>> meaning of (wchar_t)0xf7 depends on locales: in some locale it may be
<br>> a DIVISION SIGN, in another one a CYRILLIC SMALL LETTER YI, in another
<br>> one a LATIN SMALL LETTER S WITH ACUTE, and in another one it's invalid.
<br><br>Locales with non-Unicode wchar_t are far worse than locales
<br>with non-UTF-8 char. Lots of software breaks, and nobody will
<br>fix it. There comes a time to deprecate dysfunctional locales.
<br><br>>> d. The "C" locale ignores LC_MESSAGES, even if not "C".
<br>>
<br>> What do you expect the system to do when you set LC_ALL to "C" and
<br>> then LC_MESSAGES to "zh_CN"? All characters are US-ASCII but messages
<br>> should be in Chinese? In earlier versions of glibc, the Chinese strings
<br>> were converted to "?????? ??? ?????? 32 ?????" before being displayed.
<br>> This was not really helpful; so now the translations are ignored
<br>> entirely in this case.
<br><br>Just be binary-clean. Remember why UTF-8 was invented.
<br>If glibc were binary clean, messages would normally just work.
<br>They would certainly work for typical GUI stuff using Pango,
<br>and would even work in many terminal situations.
<br><br>>> e. The locale reverts to "C" if some portion is missing/unknown.
<br>>
<br>> What's wrong with having a fallback if some portion is missing?
<br><br>Nothing. The problem is how this interacts with the other stuff.
<br>If the fallback were something like "C.UTF-8" or the "C" locale
<br>wasn't severely limited, there would be no problem.
<br><br>It's only the combination of all these design issues that results in
<br>a problem. Individually, no one design issue is really a problem.
<br><br>>> The result is that none of these work:
<br>>>
<br>>> a. setlocale(LC_ALL,"zam");
<br>>> b. setlocale(LC_MESSAGES,"zam");
<br>>> c. setlocale(LC_MESSAGES,"zam"); setlocale(LC_CTYPE,"UTF-8");
<br>>
<br>> None of these work because you don't have a "zam" locale installed in
<br>> the first place. setlocale is about designating locales to use.
<br><br>I have a piece of a locale installed. (my "zam.mo" file)
<br>To use that, I mainly just need a binary-clean library.
<br>Getting iswprint() and towupper() would be nice too, but
<br>it's not a huge problem for me to write my own.
<br><br>Basically: use what is there, and assume something close
<br>to "C.UTF-8" for anything missing/broken. Maybe you could
<br>find choices that are more generic than "C", like 24-hour time
<br>and PA4 paper size. Maybe round-trip the case for U+1E9E,
<br>avoiding expansion troubles. You could call it "default.UTF-8".
<br><br>The details aren't terribly critical; the main thing is to let a
<br>random loose UTF-8 *.mo file work without hacks or fuss,
<br>along with the wchar_t functions working beyond ASCII.
<br><br>>> There just doesn't seem to be any reasonable way to kick gettext into
<br>>> UTF-8 mode and feed it a *.mo file.
<br>>
<br>> You found the way and showed it to us.
<br><br>Trying random unrelated locales and calling putenv() is
<br>pretty far from reasonable IMHO.
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26551936Re: supporting obscure languages2009-11-28T02:34:55Z2009-11-28T02:34:55ZBruno HaibleAlbert Cahalan wrote:
<div class='shrinkable-quote'><br>> Well, that's the language I'm currently using for testing.
<br>> I'm sure it's not the only thing failing. I have:
<br>>
<br>> af.po de.po fi.po id.po nb.po shs.po tlh.po
<br>> ar.po el.po fo.po is.po nl.po sk.po tr.po
<br>> ast.po en_AU.po fr.po it.po nn.po sl.po twi.po
<br>> az.po en_CA.po ga.po ja.po nr.po son.po uk.po
<br>> be.po en_GB.po gd.po ka.po oc.po sq.po ve.po
<br>> bg.po en_ZA.po gl.po km.po oj.po sr.po vi.po
<br>> bo.po eo.po gos.po ko.po pl.po sv.po wa.po
<br>> br.po es.po gu.po ku.po pt.po sw.po wo.po
<br>> ca.po es_MX.po he.po lt.po pt_BR.po ta.po xh.po
<br>> cs.po et.po hi.po lv.po ro.po te.po zam.po
<br>> cy.po eu.po hr.po mk.po ru.po th.po zh_CN.po
<br>> da.po fa.po hu.po ms.po rw.po tl.po zh_TW.po
</div><br>84 languages! That is impressing. The largest number of translations
<br>of a package in the Translation Project is currently 58 languages.
<br><div class='shrinkable-quote'><br>> > 2) You may need to define a glibc locale. This is necessary for a
<br>> > distinct language and optional for a variant (need it only if you
<br>> > want to override some localizations). You need it because things
<br>> > like month name, time display rules and the like are not defined
<br>> > by .po files but through a locale definition.
<br>>
<br>> ... Tux Paint sure doesn't need any of that.
<br>> I don't need month name, time display rules, telephone formats...
<br>>
<br>> All I care about: LC_MESSAGES for "zam", LC_CTYPE not lobotomized
</div><br>Then your workaround of doing
<br> LANGUAGE=zam LC_ALL=fr_FR.UTF-8
<br>is just fine.
<br><br>> I need two ways to make this happen. First, via the environment.
<br>> Second, via function calls so that I can have the --locale=zam
<br>> and --lang=zapotec options work.
<br><br>For the first way, you can refer the user to the GNU gettext documentation
<br> <a href="http://www.gnu.org/software/gettext/manual/html_node/Users.html" target="_top" rel="nofollow">http://www.gnu.org/software/gettext/manual/html_node/Users.html</a><br>or tell them to set LANGUAGE, if you prefer that.
<br><br>For the second way, you can call
<br> setenv ("LC_ALL", "fr_FR.UTF-8", 1);
<br> setenv ("LANGUAGE", "zam", 1);
<br><br>> BTW, we'd like fallback to similar translations in case something
<br>> is missing. When zh_TW.mo lacks something, zh_CN.mo should be the
<br>> next place to look.
<br><br>That's a built-in feature in GNU gettext: just set the LANGUAGE variable to
<br> zh_TW:zh_CN
<br>and you're done.
<br><br>> I end up with glibc's broken "C" locale.
<br>> Tux Paint's code does this now:
<br>>
<br>> setlocale(LC_ALL, loc); // loc="" or loc="zam"
<br>> ctype_utf8(); // setlocale(LC_CTYPE,x) for many x until iswprint works
<br><br>Yes, you have no guarantee that a particular locale is installed on the user's
<br>system. You have to try some. setlocale(LC_ALL, "") is a good first guess.
<br><br>> bindtextdomain("tuxpaint", LOCALEDIR);
<br>> bind_textdomain_codeset("tuxpaint", "UTF-8");
<br>> textdomain("tuxpaint");
<br><br>Right.
<br><br>> The i18n source is here:
<br>> <a href="http://tuxpaint.cvs.sf.net/viewvc/tuxpaint/tuxpaint/src/i18n.c?revision=1.72" target="_top" rel="nofollow">http://tuxpaint.cvs.sf.net/viewvc/tuxpaint/tuxpaint/src/i18n.c?revision=1.72</a><br>>
<br>> The interesting stuff starts in the set_current_locale(char *locale)
<br>> function, with the requested locale being "" or from the command line.
<br><br>Looks reasonable.
<br><br>> My current hack: LANGUAGE=zam LC_ALL=fr_FR.UTF-8
<br>>
<br>> Yep, I'm telling gettext that this is French. That's disgusting.
<br><br>No, you are telling the system to use an UTF-8 encoding for strings,
<br>French rules for time, sorting, numbers etc, and Zapotec for messages.
<br>If it fits well with your program, all fine.
<br><br>> There are quite a few design bugs here, none of which would cause
<br>> huge problems all by itself. Together, they are a disaster.
<br>>
<br>> a. The implementation-specific "" locale is "C". (it need not be)
<br><br>No, when you call setlocale(LC_ALL,"") it uses the locale that the
<br>user has set, not "C".
<br><br>> b. The "C" locale is not UTF-8. (this need not be the case)
<br><br>The "C" locale was defined at a time when there was no UTF-8. This
<br>choice accommodates for output devices that cannot display arbitrary
<br>Unicode characters (think of ssh into an older Unix system).
<br><br>> c. The "C" locale makes iswprint((wchar_t)0xf7) be false. (very bad)
<br><br>I agree with you that wide characters are a mess in ISO C, because the
<br>meaning of (wchar_t)0xf7 depends on locales: in some locale it may be
<br>a DIVISION SIGN, in another one a CYRILLIC SMALL LETTER YI, in another
<br>one a LATIN SMALL LETTER S WITH ACUTE, and in another one it's invalid.
<br><br>> d. The "C" locale ignores LC_MESSAGES, even if not "C".
<br><br>What do you expect the system to do when you set LC_ALL to "C" and
<br>then LC_MESSAGES to "zh_CN"? All characters are US-ASCII but messages
<br>should be in Chinese? In earlier versions of glibc, the Chinese strings
<br>were converted to "?????? ??? ?????? 32 ?????" before being displayed.
<br>This was not really helpful; so now the translations are ignored
<br>entirely in this case.
<br><br>> e. The locale reverts to "C" if some portion is missing/unknown.
<br><br>What's wrong with having a fallback if some portion is missing?
<br><br>> The result is that none of these work:
<br>>
<br>> a. setlocale(LC_ALL,"zam");
<br>> b. setlocale(LC_MESSAGES,"zam");
<br>> c. setlocale(LC_MESSAGES,"zam"); setlocale(LC_CTYPE,"UTF-8");
<br><br>None of these work because you don't have a "zam" locale installed in
<br>the first place. setlocale is about designating locales to use.
<br><br>> There just doesn't seem to be any reasonable way to kick gettext into
<br>> UTF-8 mode and feed it a *.mo file.
<br><br>You found the way and showed it to us.
<br><br>Bruno
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26551494Re: supporting obscure languages2009-11-28T01:28:57Z2009-11-28T01:28:57ZBruno HaibleJohn Cowan wrote:
<br>> Is there any reason why ISO 639-3 identifiers cannot be used for
<br>> appropriate languages? 639-3 is much more comprehensive than 639-2, and
<br>> the identifiers correspond (that is, since 'haw' is Hawaiian in 639-2,
<br>> it has the same meaning in 639-3).
<br><br>ISO 639-2 has stronger rules about stability: Codes in ISO 639-2/B will not
<br>be changed, and the other ISO 639-2 can be changed, but an old code will not
<br>be reused for another language for 5 years. Whereas in ISO 639-3 there are
<br>large changes every year [1].
<br><br>> In short, unless there is some technical barrier to using 639-3 code
<br>> elements, it is more appropriate to code this language as "zam" rather
<br>> than as "zap@miahuatlan".
<br><br>From the linguistic point of view, you may be right.
<br><br>From the point of stability of the code, if you choose "zam", you have to
<br>consider the possibility that the code be changed at some point in the
<br>future. This is not impossible to do - we had a change from 'no@nynorsk' to
<br>'nn' a couple of years ago - but it causes trouble to the users of that
<br>language for some years.
<br><br>Bruno
<br><br>[1] <a href="http://www.sil.org/iso639-3/changes.asp" target="_top" rel="nofollow">http://www.sil.org/iso639-3/changes.asp</a><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26549558Re: supporting obscure languages2009-11-27T15:09:12Z2009-11-27T15:09:12ZAlbert CahalanOn Fri, Nov 27, 2009 at 7:42 AM, Bruno Haible <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26549558&i=0" target="_top" rel="nofollow">bruno@...</a>> wrote:
<br><br>> You did not state what you are trying to do. I understand it like this:
<br>> "How do I add support for a specific, rarely used language to my system
<br>> in such a way that I can localize programs for this language?"
<br><br>I'm interested in that, and I think it should be trivial, but I'm
<br>actually dealing with this from the view of a software developer
<br>with existing *.mo files. I'm working on Tux Paint.
<br><br>(think of the children)
<br><br>At this point I'm seriously considering ripping out the gettext
<br>stuff because it is fighting me every step of the way. It looks
<br>like less trouble to write my own; we already do this for audio
<br>and fonts. I hope you wish for gettext to be easy to work with.
<br><br>> 1) You need to define a locale identifier for it. This is important,
<br>> because the users and all translators must agree on it - if a
<br>> translator uses a different identifier than the user, her
<br>> translations will not be found. The standardized identifiers
<br>> are those in ISO 639-1 and ISO 639-2, and also found in glibc's
<br>> glibc/locale/iso-639.def.
<br><br>Done. It's some Zapotec thing that I know very little about.
<br>I'm not the translator. The translator(s) decided, and I'm
<br>certainly not about to argue.
<br><br>Well, that's the language I'm currently using for testing.
<br>I'm sure it's not the only thing failing. I have:
<br><br>af.po de.po fi.po id.po nb.po shs.po tlh.po
<br>ar.po el.po fo.po is.po nl.po sk.po tr.po
<br>ast.po en_AU.po fr.po it.po nn.po sl.po twi.po
<br>az.po en_CA.po ga.po ja.po nr.po son.po uk.po
<br>be.po en_GB.po gd.po ka.po oc.po sq.po ve.po
<br>bg.po en_ZA.po gl.po km.po oj.po sr.po vi.po
<br>bo.po eo.po gos.po ko.po pl.po sv.po wa.po
<br>br.po es.po gu.po ku.po pt.po sw.po wo.po
<br>ca.po es_MX.po he.po lt.po pt_BR.po ta.po xh.po
<br>cs.po et.po hi.po lv.po ro.po te.po zam.po
<br>cy.po eu.po hr.po mk.po ru.po th.po zh_CN.po
<br>da.po fa.po hu.po ms.po rw.po tl.po zh_TW.po
<br><br>(ever see that many at once before?)
<br><br>> 2) You may need to define a glibc locale. This is necessary for a
<br>> distinct language and optional for a variant (need it only if you
<br>> want to override some localizations). You need it because things
<br>> like month name, time display rules and the like are not defined
<br>> by .po files but through a locale definition.
<br><br>Frankly, I don't give a shit. If somebody decides they care, they
<br>can define these things. Tux Paint sure doesn't need any of that.
<br>I don't need month name, time display rules, telephone formats...
<br><br>All I care about: LC_MESSAGES for "zam", LC_CTYPE not lobotomized
<br><br>I need two ways to make this happen. First, via the environment.
<br>Second, via function calls so that I can have the --locale=zam
<br>and --lang=zapotec options work.
<br><br>> To create a locale, use the
<br>> "localedef" command together with a locale definition file. There
<br>> are dozens of examples of these locale definition files in a
<br>> directory mentioned in the output of "localedef --help".
<br><br>That would be complicated sysadmin work. These machines probably
<br>run es_MX.UTF-8 most of the time, or maybe C. Nobody wants to wait
<br>for Fedora or Debian to take their sweet time adding "zam".
<br>This also, somehow, needs to work for Windows and MacOS X. It will
<br>be a cold day in Hell before Microsoft or Apple supports Zapotec.
<br><br>> 3) Then you can create .mo files from .po files for that language,
<br>> as described in the GNU gettext documentation.
<br><br>Done. Tux Paint includes 84 translations.
<br><br>BTW, we'd like fallback to similar translations in case something
<br>is missing. When zh_TW.mo lacks something, zh_CN.mo should be the
<br>next place to look.
<br><br>>> How can a program offer a non-environment way to override the source
<br>>> of messages? The obvious setlocale(LC_ALL,"zam") does not work, nor
<br>>> does the troublesome (because other locales need more) substitution
<br>>> of setlocale(LC_MESSAGES,"zam").
<br>>
<br>> There is setlocale, and there is bindtextdomain. But you should have a
<br>> locale first.
<br><br>It doesn't work. I end up with glibc's broken "C" locale.
<br>Tux Paint's code does this now:
<br><br>setlocale(LC_ALL, loc); // loc="" or loc="zam"
<br>ctype_utf8(); // setlocale(LC_CTYPE,x) for many x until iswprint works
<br>bindtextdomain("tuxpaint", LOCALEDIR);
<br>bind_textdomain_codeset("tuxpaint", "UTF-8");
<br>textdomain("tuxpaint");
<br><br>The i18n source is here:
<br><a href="http://tuxpaint.cvs.sf.net/viewvc/tuxpaint/tuxpaint/src/i18n.c?revision=1.72" target="_top" rel="nofollow">http://tuxpaint.cvs.sf.net/viewvc/tuxpaint/tuxpaint/src/i18n.c?revision=1.72</a><br><br>The interesting stuff starts in the set_current_locale(char *locale)
<br>function, with the requested locale being "" or from the command line.
<br><br>>> BTW, please consider it a bug that that doesn't just work.
<br>>
<br>> No, not a bug. This is the way locales are designed.
<br><br>That makes it a design bug.
<br><br>My current hack: LANGUAGE=zam LC_ALL=fr_FR.UTF-8
<br><br>Yep, I'm telling gettext that this is French. That's disgusting.
<br><br>There are quite a few design bugs here, none of which would cause
<br>huge problems all by itself. Together, they are a disaster.
<br><br>a. The implementation-specific "" locale is "C". (it need not be)
<br>b. The "C" locale is not UTF-8. (this need not be the case)
<br>c. The "C" locale makes iswprint((wchar_t)0xf7) be false. (very bad)
<br>d. The "C" locale ignores LC_MESSAGES, even if not "C".
<br>e. The locale reverts to "C" if some portion is missing/unknown.
<br><br>The result is that none of these work:
<br><br>a. setlocale(LC_ALL,"zam");
<br>b. setlocale(LC_MESSAGES,"zam");
<br>c. setlocale(LC_MESSAGES,"zam"); setlocale(LC_CTYPE,"UTF-8");
<br><br>All should do the job, using any info that is available and picking
<br>generic modern choices for the rest.
<br><br>There just doesn't seem to be any reasonable way to kick gettext into
<br>UTF-8 mode and feed it a *.mo file. This should be more than easy; it
<br>should be what you tend to end up with when things aren't consistant.
<br><br>I could see "C" being Latin-1 by default instead of UTF-8 (though wide
<br>character functions should still support full Unicode), and I could see
<br>having message lookup disabled if **nothing** non-C is enabled. Once I
<br>call bind_textdomain_codeset("tuxpaint","UTF-8") or setlocale(foo,"zam")
<br>though, it should be obvious what gettext needs to do.
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26547353Re: The awk bug2009-11-27T12:21:32Z2009-11-27T12:21:32ZJohn CowanKaplenko Vitaliy scripsit:
<br><br>> $ echo "./some_script" | awk 'gsub(".","a") {print $0}'
<br>> aaaaaaaaaaaaa
<br>>
<br>> But must be:
<br>>
<br>> $ echo "./some_script" | awk 'gsub(".","a") {print $0}'
<br>> a/some_script
<br><br>Not so. The first argument of gsub is interpreted as a regular
<br>expression, and "." in a regular expression means "any character".
<br>Consequently, all characters in the input are replaced. You must use
<br>"\." to match a literal dot.
<br><br>> $ echo "some_script" | awk 'gsub("/","a") {print $0}'
<br>> $
<br>>
<br>> But must be:
<br>>
<br>> $ echo "some_script" | awk 'gsub("/","a") {print $0}'
<br>> $ some_script
<br><br>Also not the case. You have placed the call to gsub into the pattern
<br>part of the pattern-action statement. Consequently, it evaluates to 0
<br>because there are no slashes in the input, and therefore the action is
<br>never executed. A correct action statement would be
<br><br> {gsub("/", a); print $0}
<br><br>--
<br>A rabbi whose congregation doesn't want John Cowan
<br>to drive him out of town isn't a rabbi, <a href="http://www.ccil.org/~cowan" target="_top" rel="nofollow">http://www.ccil.org/~cowan</a><br>and a rabbi who lets them do it <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26547353&i=0" target="_top" rel="nofollow">cowan@...</a>
<br>isn't a man. --Jewish saying
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26546097Re: supporting obscure languages2009-11-27T10:17:20Z2009-11-27T10:17:20ZJohn CowanBruno Haible scripsit:
<br><br>> 1) You need to define a locale identifier for it. This is important,
<br>> because the users and all translators must agree on it - if a
<br>> translator uses a different identifier than the user, her
<br>> translations will not be found. The standardized identifiers
<br>> are those in ISO 639-1 and ISO 639-2, and also found in glibc's
<br>> glibc/locale/iso-639.def.
<br><br>Is there any reason why ISO 639-3 identifiers cannot be used for
<br>appropriate languages? 639-3 is much more comprehensive than 639-2, and
<br>the identifiers correspond (that is, since 'haw' is Hawaiian in 639-2,
<br>it has the same meaning in 639-3).
<br><br>> If your language is a distinct one, you should find the language
<br>> identifier in this list. If your language is a dialect of another
<br>> language, you can use a variant tag. For example, if by "zam" you
<br>> mean the language "Zapotec, Miahuatlán", it is a dialect of
<br>> Zapotec, which has the identifier "zap". So you will likely
<br>> choose the language identifier "zap@miahuatlan" (all ASCII please).
<br><br>"Zapotec" is what 639-3 calls a macrolanguage: that is, it is a collection
<br>of closely related languages that is for some purposes treated as a
<br>single language. The Zapotec macrolanguage encompasses 58 languages.
<br>I emphasize that these are distinct languages, not at all mutually
<br>intelligible. Calling them "dialects of Zapotec" is exactly like calling
<br>French, Spanish, and Italian "dialects of Latin": it reflects an old
<br>unity that has long since been lost.
<br><br>Furthermore, no one Zapotec language is either numerically or culturally
<br>dominant: Isthmus Zapotec (zai), the largest, has perhaps 85,000 speakers
<br>out of a total Zapotec-speaking population of 500,000. This makes it
<br>quite different from better known macrolanguages such as Arabic (which
<br>encompasses about 30 languages, with Standard Arabic culturally but
<br>not numerically dominant) and Chinese (which encompasses 13 languages,
<br>with Mandarin both culturally and numerically dominant).
<br><br>In short, unless there is some technical barrier to using 639-3 code
<br>elements, it is more appropriate to code this language as "zam" rather
<br>than as "zap@miahuatlan".
<br><br>--
<br>The Imperials are decadent, 300 pound John Cowan <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26546097&i=0" target="_top" rel="nofollow">cowan@...</a>>
<br>free-range chickens (except they have <a href="http://www.ccil.org/~cowan" target="_top" rel="nofollow">http://www.ccil.org/~cowan</a><br>teeth, arms instead of wings, and
<br>dinosaurlike tails). --Elyse Grasso
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26546849The awk bug 22009-11-27T08:50:01Z2009-11-27T08:50:01ZKaplenko VitalijIf run
<br>in Linux localhost.localdomain 2.6.29.5-191.fc11.i686.PAE #1 SMP Tue Jun
<br>16 23:19:53 EDT 2009 i686 i686 i386 GNU/Linux:
<br><br>$ echo "some_script" | awk 'gsub("/","a") {print $0}'
<br>$
<br><br>But must be:
<br><br>$ echo "some_script" | awk 'gsub("/","a") {print $0}'
<br>$ some_script
<br><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26546846The awk bug2009-11-27T08:31:23Z2009-11-27T08:31:23ZKaplenko VitalijIf run
<br>in Linux localhost.localdomain 2.6.29.5-191.fc11.i686.PAE #1 SMP Tue Jun
<br>16 23:19:53 EDT 2009 i686 i686 i386 GNU/Linux:
<br><br>$ echo "./some_script" | awk 'gsub(".","a") {print $0}'
<br>aaaaaaaaaaaaa
<br><br>But must be:
<br><br>$ echo "./some_script" | awk 'gsub(".","a") {print $0}'
<br>a/some_script
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26542035Re: supporting obscure languages2009-11-27T04:42:38Z2009-11-27T04:42:38ZBruno HaibleHi Albert,
<br><br>You did not state what you are trying to do. I understand it like this:
<br>"How do I add support for a specific, rarely used language to my system
<br> in such a way that I can localize programs for this language?"
<br><br>The answer is:
<br><br>1) You need to define a locale identifier for it. This is important,
<br> because the users and all translators must agree on it - if a
<br> translator uses a different identifier than the user, her
<br> translations will not be found. The standardized identifiers
<br> are those in ISO 639-1 and ISO 639-2, and also found in glibc's
<br> glibc/locale/iso-639.def.
<br><br> If your language is a distinct one, you should find the language
<br> identifier in this list. If your language is a dialect of another
<br> language, you can use a variant tag. For example, if by "zam" you
<br> mean the language "Zapotec, Miahuatlán", it is a dialect of
<br> Zapotec, which has the identifier "zap". So you will likely
<br> choose the language identifier "zap@miahuatlan" (all ASCII please).
<br><br>2) You may need to define a glibc locale. This is necessary for a
<br> distinct language and optional for a variant (need it only if you
<br> want to override some localizations). You need it because things
<br> like month name, time display rules and the like are not defined
<br> by .po files but through a locale definition. To create a locale, use the
<br> "localedef" command together with a locale definition file. There
<br> are dozens of examples of these locale definition files in a
<br> directory mentioned in the output of "localedef --help".
<br><br>3) Then you can create .mo files from .po files for that language,
<br> as described in the GNU gettext documentation.
<br><br>Albert Cahalan wrote:
<br>> Given a fairly normal program, how can the user force the use of a
<br>> specific known messages file? Consider /tmp/testfile.mo in a locale
<br>> that isn't otherwise defined in any way.
<br><br>You can set the environment variable LOCALEDIR to, say, /tmp/locale,
<br>and then store the file as /tmp/locale/$localeID/LC_MESSAGES/testfile.mo.
<br><br>> Now suppose that the file is stored in the expected place. The user
<br>> wants to use /usr/share/locale/zam/LC_MESSAGES/someprog.mo with a
<br>> program that claims to be someprog. Again, the locale isn't supported
<br>> in any other way; there is merely a *.mo file installed.
<br><br>This is only supported in the dialect case. If you choose the
<br>language identifier "zap@miahuatlan" and the user's locale identifier
<br>is zap_MX.UTF-8@miahuatlan, you need only a zap_MX.UTF-8 locale; a
<br>zap_MX.UTF-8@miahuatlan locale does not need to exist.
<br><br>> How can a program offer a non-environment way to override the source
<br>> of messages? The obvious setlocale(LC_ALL,"zam") does not work, nor
<br>> does the troublesome (because other locales need more) substitution
<br>> of setlocale(LC_MESSAGES,"zam").
<br><br>There is setlocale, and there is bindtextdomain. But you should have a
<br>locale first.
<br><br>> BTW, please consider it a bug that that doesn't just work.
<br><br>No, not a bug. This is the way locales are designed.
<br><br>Bruno
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26538776supporting obscure languages2009-11-26T10:28:50Z2009-11-26T10:28:50ZAlbert CahalanFirst, you may assume that the locale is UTF-8. We only care about
<br>the messages and getting stuff like iswprint or towupper to work in
<br>the default (no Turkish i, etc.) Unicode way.
<br><br>Given a fairly normal program, how can the user force the use of a
<br>specific known messages file? Consider /tmp/testfile.mo in a locale
<br>that isn't otherwise defined in any way.
<br><br>Now suppose that the file is stored in the expected place. The user
<br>wants to use /usr/share/locale/zam/LC_MESSAGES/someprog.mo with a
<br>program that claims to be someprog. Again, the locale isn't supported
<br>in any other way; there is merely a *.mo file installed. Without
<br>giving the full path, and with minimal complexity, how can the user
<br>get this file to be used?
<br><br>How can a program offer a non-environment way to override the source
<br>of messages? The obvious setlocale(LC_ALL,"zam") does not work, nor
<br>does the troublesome (because other locales need more) substitution
<br>of setlocale(LC_MESSAGES,"zam").
<br><br>BTW, please consider it a bug that that doesn't just work.
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26508979Re: wint_t in cross building, gnulib failing build.2009-11-25T00:23:54Z2009-11-25T00:23:54ZLluís BatlleHello,
<br><br>thank you very much for your answer.
<br><br>2009/11/25 Bruno Haible <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26508979&i=0" target="_top" rel="nofollow">bruno@...</a>>:
<br>> You might therefore want to try the newest gettext from git, combined
<br>> with the newest gnulib from git. Be sure to look at the gettext/HACKING file.
<br><br>I think I will wait for the next release, because by now I have a
<br>solution to get all working. I only wanted to understand a bit the
<br>logic behind the 'configure' decisions I was seeing, in order to learn
<br>from something I was not understanding.
<br>But now I'm happy that I was understanding, and there are fixes in
<br>newer versions of the code.
<br><br>Regards,
<br>Lluís.
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26504946Re: wint_t in cross building, gnulib failing build.2009-11-24T15:08:15Z2009-11-24T15:08:15ZBruno HaibleHi,
<br><br>Lluís Batlle wrote:
<br>> I'm trying to cross-build gettext, and with my toolchain (gcc 4.3.4
<br>> and glibc-2.9 for armv5tel-linux) I have problems, while I don't have
<br>> any problem building it not natively.
<br>>
<br>> I found that the gettext-runtime configure has a check like this:
<br>> if test "$cross_compiling" = yes; then
<br>> gl_cv_func_wcwidth_works="guessing no"
<br><br>This has been improved in gnulib on 2009-07-14: it will now guess "yes"
<br>on glibc systems and "no" elsewhere.
<br><br>> In native builds (where I use the same compiler and glibc version) I
<br>> have gl_cv_func_wcwidth_works=yes, and having this defined as 'no'
<br>> results in gettext-runtime/gnulib-lib/ use its own 'wchar.h' created
<br>> from 'wchar.h.in'
<br><br>This should be redundant but harmless.
<br><br>> and this wchar.h ends up not having wint_t defined
<br>> as required in glibc's wchar.h, included through mbchar.h in
<br>> gnulib-lib.
<br><br>This has been fixed in gnulib on 2009-01-15 and 2009-01-17.
<br><br>You might therefore want to try the newest gettext from git, combined
<br>with the newest gnulib from git. Be sure to look at the gettext/HACKING file.
<br><br>> I'm going to go on using a cache-file, and setting
<br>> gl_cv_func_wcwidth_works=yes there
<br><br>Yes, this should work. You can also pass gl_cv_func_wcwidth_works=yes as
<br>an environment variable setting while running configure.
<br><br>> but I would like to know why this
<br>> mbchar build fails for me having no wint_t type defined. Why
<br>> cross-compiling the wcwidth function would not work?
<br><br>Simply, it had not been tested before the release of gettext 0.17.
<br><br>Bruno
<br><br>[1] <a href="https://savannah.gnu.org/git/?group=gettext" target="_top" rel="nofollow">https://savannah.gnu.org/git/?group=gettext</a><br>[2] <a href="https://savannah.gnu.org/git/?group=gnulib" target="_top" rel="nofollow">https://savannah.gnu.org/git/?group=gnulib</a><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26487896wint_t in cross building, gnulib failing build.2009-11-23T10:35:15Z2009-11-23T10:35:15ZLluís BatlleHello,
<br><br>I'm trying to cross-build gettext, and with my toolchain (gcc 4.3.4
<br>and glibc-2.9 for armv5tel-linux) I have problems, while I don't have
<br>any problem building it not natively.
<br><br>I found that the gettext-runtime configure has a check like this:
<br> if test "$cross_compiling" = yes; then
<br> gl_cv_func_wcwidth_works="guessing no"
<br><br>In native builds (where I use the same compiler and glibc version) I
<br>have gl_cv_func_wcwidth_works=yes, and having this defined as 'no'
<br>results in gettext-runtime/gnulib-lib/ use its own 'wchar.h' created
<br>from 'wchar.h.in', and this wchar.h ends up not having wint_t defined
<br>as required in glibc's wchar.h, included through mbchar.h in
<br>gnulib-lib.
<br><br>I'm going to go on using a cache-file, and setting
<br>gl_cv_func_wcwidth_works=yes there, but I would like to know why this
<br>mbchar build fails for me having no wint_t type defined. Why
<br>cross-compiling the wcwidth function would not work?
<br><br>Regards,
<br>Lluís.
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26467516XMLgawk for Windows2009-11-22T08:37:28Z2009-11-22T08:37:28ZWim van Blitterswijk-2<br> Hello developers,
<br> As mentioned in my mail of 5 November, I managed to build XMLgawk for native
<br> Windows :-) .
<br> In the previous version, however, I forgot the dependency on libiconv-2.dll.
<br> (The dll was already on the path in my environment, so it worked in my
<br> case.) The file is now included in the archive that can be downloaded from
<br> my site:
<br> [1]<a href="http://www.wimdows.info/project/xmlgawk" target="_top" rel="nofollow">http://www.wimdows.info/project/xmlgawk</a><br> To use the new gawk.exe, with xml support:
<br> - The dynamic library xml.dll needs to be on your AWKLIBPATH or in the
<br> current working directory,
<br> - The dll's libexpat-1.dll and libiconv-2.dll (and gawk.exe) need to be on
<br> your path.
<br> Hope you will be able to use the binaries now.
<br> Regards,
<br> Wim van Blitterswijk
<br> Wim van Blitterswijk wrote:
<br><br> Hello developers,
<br> After some hard work I seem to be able to build XMLgawk for native Windows
<br> :-)
<br> Jürgen, Victor and Manuel: thanks for all the tips!
<br> If you're interested, have a look at
<br> [2]<a href="http://www.wimdows.info/project/xmlgawk" target="_top" rel="nofollow">http://www.wimdows.info/project/xmlgawk</a><br> and have fun.
<br> Regards,
<br> Wim van Blitterswijk
<br><br>References
<br><br> 1. <a href="http://www.wimdows.info/project/xmlgawk" target="_top" rel="nofollow">http://www.wimdows.info/project/xmlgawk</a><br> 2. <a href="http://www.wimdows.info/project/xmlgawk" target="_top" rel="nofollow">http://www.wimdows.info/project/xmlgawk</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26458906GNU gettest manual2009-11-21T04:06:11Z2009-11-21T04:06:11ZBugzilla from publi@web.deHi,
<br><br>I have got a version of the preliminary draft GNU gettext documenation on my
<br>computer with poedit. It says:
<br><br>Edition 0.10.35, 1 May 1998
<br><br>That is 10 years old, wouw.
<br><br>It publishes an outdated e-mai address which should be updated:
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26458906&i=0" target="_top" rel="nofollow">bug-gnu-utils@...</a>>: host mx10.gnu.org[199.232.76.166] said: 550
<br>*.ai.mit.edu no longer in use. use @gnu.org instead. (in reply to RCPT TO
<br>command)
<br><br>Few remarks:
<br><br> In "Aspects in Native Language Support" it talks of countries a lot. This is
<br>misguiding, and too imprecise. "Cultures or Regions" would be the better
<br>term. Beware: Many major languages like Chinese, English, Spanish,
<br>Arabic,Bengali, Portuguese, Swahili German, Kurdi, Azeri, Dutch are spoken in
<br>several or even many countries and continents. Some languages are spoken only
<br>in federal states, provinces, regions, vallies, islands, cities, or even
<br>villages inside a country. Many countries have many languages, such as India
<br>(260+), Philipines (~80), South Africa, and so on. Some areas are having
<br>mixed languages, for instance East Belgium has French, Wallon, German, and
<br>vernacular, and very many people are fluent using either. While i18n may use
<br>an open set lof languages, L18n has a complicated set of mixes and
<br>dependencies on language, culture, and the like.
<br><br> One thing hardly taken care of is that peoples multilinguality varies.
<br>Setting a computer to use, say, russian, is by far insufficient. In fact, one
<br>would need to tell on a per user basis, which language / locale to use, and a
<br>series of fallbacks, to be used in such cases, where all more perferred L18ns
<br>are unavaliable, This thinking needs to be reflected in each program, or at
<br>least the libraries it is using. All GUI program should allow interactive and
<br>instant switching between languages and locales, so as to aid people who are
<br>not sure to have understood something right in one language or with one
<br>locale, and to support changing users at the screen without having to reboot.
<br><br> It is fairly insufficient, only to translate strings. Parameter insertion is
<br>needed, parameter typing is needed, case switching is needed (for instance on
<br>various grammatical forms, numbers, genders, addressing modes and
<br>politeness, to name only a few) and programs, programmers, screen designers
<br>and layouters need to be aware of the flexibility required by the outcomes.
<br><br>Hints:
<br><a href="http://www.mediawiki.org/wiki/I18n" target="_top" rel="nofollow">http://www.mediawiki.org/wiki/I18n</a><br><a href="http://cldr.unicode.org/" target="_top" rel="nofollow">http://cldr.unicode.org/</a><br><br>Greetings - Purodha Blissenbach, <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26458906&i=1" target="_top" rel="nofollow">publi@...</a>>
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26403027gettext 0.17 doesn't build on mingw2009-11-17T15:55:56Z2009-11-17T15:55:56ZRainer Emrich-2-----BEGIN PGP SIGNED MESSAGE-----
<br>Hash: SHA1
<br><br>gettext 0.17 doesn't build on mingw, because mingw's _mkdir() function has 1
<br>argument and gettext is passing 2 arguments.
<br>Possible solution would be to pull in the gnulib mkdir, no?
<br><br>Cheers,
<br>Rainer
<br>-----BEGIN PGP SIGNATURE-----
<br>Version: GnuPG v1.4.10 (MingW32)
<br>Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/" target="_top" rel="nofollow">http://enigmail.mozdev.org/</a><br><br>iEYEARECAAYFAksDOAwACgkQoUhjsh59BL6pPQCfXdTeDWoKzH0MfvJmlk9YFqkw
<br>woAAn2kDFmlGL8IAZiXx3qV/VJQnkBbb
<br>=fy7l
<br>-----END PGP SIGNATURE-----
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26389619Re: GNU make: multiple patterns for prerequisites2009-11-17T03:46:28Z2009-11-17T03:46:28Zbocadillodeatun@gmail.comOk. Thanks.
<br><br>I guess it's not that bad after all :)
<br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Help-f1829.html" embed="fixTarget[1829]" target="_top" >Gnu - Utils - Help</a></p>tag:old.nabble.com,2006:post-26385535Re: Small typo in diffutils Spanish translation2009-11-16T23:30:29Z2009-11-16T23:30:29ZJim MeyeringGermán Bassi wrote:
<br>> I've spotted a small typo in the Spanish translation of diff and here
<br>> is a patch to fix it.
<br>>
<br>> There's a debian bug report [1] about it but they told me to contact you.
<br>>
<br>> Thank you,
<br>> Germán Bassi.
<br>>
<br>> [1] <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481708" target="_top" rel="nofollow">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481708</a><br><br>Thanks for persevering. You're almost done ;-)
<br><br>Actually, we pull translations automatically from the
<br>translationproject.org, so the Spanish translators there:
<br><br> <a href="http://translationproject.org/team/es.html" target="_top" rel="nofollow">http://translationproject.org/team/es.html</a><br><br>Here's the team address:
<br><br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26385535&i=0" target="_top" rel="nofollow">es@...</a>
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26381065Re: GNU make: multiple patterns for prerequisites2009-11-16T14:01:10Z2009-11-16T14:01:10ZHenrik Carlqvist-4bocadillodeatun <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26381065&i=0" target="_top" rel="nofollow">bocadillodeatun@...</a>> wrote:
<br>> I have somethign like this:
<br>>
<br>> one.o two.o : %.o :%.c
<br><br>> However, some of my source files can be either ".c" or ".S".
<br>> So... is there any way to tell "make" to look in VPATH for files that
<br>> match either one or another ?
<br><br>Yes, use two rules:
<br><br>one.o two.o : %.o :%.c
<br><br>one.o two.o : %.o :%.S
<br><br>> I know I could first "filter" my files in two groups, and then create
<br>> two rules... I was just wondering if this feature can be accessed
<br>> by a single rule.
<br><br>AFAIK it is not possible with only one rule.
<br><br>regards Henrik
<br>--
<br>The address in the header is only to prevent spam. My real address is:
<br>hc3(at)poolhem.se Examples of addresses which go to spammers:
<br>root@localhost postmaster@localhost
<br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Help-f1829.html" embed="fixTarget[1829]" target="_top" >Gnu - Utils - Help</a></p>tag:old.nabble.com,2006:post-26379654Small typo in diffutils Spanish translation2009-11-16T10:11:35Z2009-11-16T10:11:35ZGermán BassiHello,
<br><br>I've spotted a small typo in the Spanish translation of diff and here
<br>is a patch to fix it.
<br><br>There's a debian bug report [1] about it but they told me to contact you.
<br><br>Thank you,
<br>Germán Bassi.
<br><br>[1] <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481708" target="_top" rel="nofollow">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481708</a><br><br /><tt>[diff_es_po.patch]</tt><br /><hr align="left" width="300" /><tt>--- es.old.po 2008-05-18 00:57:44.000000000 -0300
<br>+++ es.po 2008-05-18 01:07:27.000000000 -0300
<br>@@ -830,7 +830,7 @@
<br> #: src/diff.c:1345
<br> #, c-format
<br> msgid "Files %s and %s are identical\n"
<br>-msgstr "Los ficheros %s y %s con idénticos\n"
<br>+msgstr "Los ficheros %s y %s son idénticos\n"
<br>
<br> #: src/diff3.c:26
<br> msgid "Written by Randy Smith."
<br></tt><hr align="left" width="300" /><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26379692GNU make: multiple patterns for prerequisites2009-11-16T09:25:18Z2009-11-16T09:25:18Zbocadillodeatun@gmail.comHi.
<br><br>I could not find how to do this on the manual, so any help would be
<br>appreciated.
<br><br>Given a VPATH variable, if I have somethign like this:
<br><br> one.o two.o : %.o :%.c
<br><br>..."make" will search in the VPATH folders for files named "one.c" and
<br>"two.c" and
<br>compile them.
<br><br>However, some of my source files can be either ".c" or ".S".
<br><br>So... is there any way to tell "make" to look in VPATH for files that
<br>match either
<br>one or another ?
<br><br>Options:
<br><br>1) one.o two.o : %.o : %.c %.s
<br><br> Won't works because "make" will look for "one.c" AND "one.S",
<br> and only one of them exists.
<br><br>2) one.o two.o : %.o : %.{c,S}
<br><br> Looks good, but "make" won't accept it :)
<br><br><br>I know I could first "filter" my files in two groups, and then create
<br>two rules... I was just wondering if this feature can be accessed
<br>by a single rule.
<br><br>Thanks.
<br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Help-f1829.html" embed="fixTarget[1829]" target="_top" >Gnu - Utils - Help</a></p>tag:old.nabble.com,2006:post-26371579Re: Bug with `-w' (`--ignore-all-space') option2009-11-16T05:06:32Z2009-11-16T05:06:32ZJim MeyeringAndreas Schwab wrote:
<div class='shrinkable-quote'><br>> Khalukhin Alexander <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26371579&i=0" target="_top" rel="nofollow">khalukhin@...</a>> writes:
<br>>
<br>>> Here are two simple text files:
<br>>>
<br>>> [bugman@localhost 1]$ cat test1.txt
<br>>> a a a a
<br>>>
<br>>> [bugman@localhost 1]$ cat test2.txt
<br>>> a
<br>>> a
<br>>> a
<br>>> a
<br>>>
<br>>> Now I'm trying to find difference, using -w (or --ignore-all-space) option:
<br>>>
<br>>> [bugman@localhost 1]$ diff -w test1.txt test2.txt
<br>>> 1c1,4
<br>>> < a a a a
<br>>> ---
<br>>>> a
<br>>>> a
<br>>>> a
<br>>>> a
<br>>>
<br>>>
<br>>> But judging to MANs they should have no differences:
<br>>
<br>> diff always operates on lines, which separated by newlines that are not
<br>> considered part of them.
<br>>
<br>>> <a href="http://www.gnu.org/software/diffutils/manual/html_node/diff-Options.html#diff%20Options" target="_top" rel="nofollow">http://www.gnu.org/software/diffutils/manual/html_node/diff-Options.html#diff%20Options</a><br>>> -w --ignore-all-space Ignore white space when comparing lines. See White
<br>>> Space<<a href="http://www.gnu.org/software/diffutils/manual/html_node/White-Space.html#White%20Space" target="_top" rel="nofollow">http://www.gnu.org/software/diffutils/manual/html_node/White-Space.html#White%20Space</a>>.
<br>>>
<br>>>
<br>>> <a href="http://www.gnu.org/software/diffutils/manual/html_node/White-Space.html#White%20Space" target="_top" rel="nofollow">http://www.gnu.org/software/diffutils/manual/html_node/White-Space.html#White%20Space</a><br>>> The -w and --ignore-all-space options are stronger still. They ignore
<br>>> difference even if one line has white space where the other line has
<br>>> none. White
<br>>> space characters include tab, *newline*, vertical tab, form feed, carriage
<br>>> return, and space; some locales may define additional characters to be white
<br>>> space.
<br>>>
<br>>> Is it a BUG?
<br>>
<br>> It's a documentation bug.
</div><br>Thanks for the report.
<br>FYI, that has been fixed for a while, and will
<br>be updated with the next release, which will be soon.
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26371535Re: diffutils now uses git2009-11-16T05:03:46Z2009-11-16T05:03:46ZJim MeyeringEric Blake wrote:
<br>> Jim Meyering <jim <at> meyering.net> writes:
<br>>
<br>>> <a href="http://git.savannah.gnu.org/cgit/diffutils.git/" target="_top" rel="nofollow">http://git.savannah.gnu.org/cgit/diffutils.git/</a><br>>
<br>> Thanks!
<br>>
<br>> However, you need this patch before diffutils is usable on all platforms,
<br>> because I got this link error when building on cygwin:
<br>...
<br>> Subject: [PATCH] build: avoid link failure when libsigsegv is used
<br>>
<br>> * src/Makefile.am (LDADD): Link against LIBCSTACK.
<br><br>Thanks. It is now in my queue.
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26367074Bug Report: gettext 0.17 can't extract both branches of a conditional expression for translation.2009-11-15T18:38:44Z2009-11-15T18:38:44ZShujing ZhaoHi,
<br>When gettext 0.17 extract the following .c code for translation at
<br>Linux, it can only extract the first branch.
<br><br> error (funcdef_flag
<br> ? "%qs defined in a non-class scope"
<br> : "%qs declared in a non-class scope", name);
<br><br><br>But an old version gettext 0.14.6 can extract both branches. I think it
<br>is a bug of 0.17.
<br><br>Thanks
<br>Pearly
<br><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26362833Running xgettext on diff/patch files2009-11-15T12:16:04Z2009-11-15T12:16:04ZCristian RigamontiHi, I'd like to run xgettext on some patches containing PHP code, to create a
<br>.pot file containing only strings contained in the patches, instead of all
<br>strings contained in the patched files.
<br><br>However, xgettext silently ignores the diff/patch input file, creating an empty
<br>output file. Renaming the input file with a .php extension doesn't help. It
<br>seems that xgettext actually checks the syntax of the input file and refuses to
<br>work on diff/patch files. Is this an intended behaviour or a bug?
<br><br>So far, the only way I found is to trick xgettext appending a bogus "<?php" line
<br>to the beginning of the patch, and removing any "?>" in it; but I guess if
<br>there is a more orthodox way to do it...
<br><br>Cri
<br><br>--
<br>GPG/PGP Key-Id 0x943A5F0E - <a href="http://www.linux.it/~cri/cri.asc" target="_top" rel="nofollow">http://www.linux.it/~cri/cri.asc</a><br><br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (204 bytes) <a href="http://old.nabble.com/attachment/26362833/0/signature.asc" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26362363Re: sed: getting at the current file name2009-11-15T11:24:44Z2009-11-15T11:24:44ZRalf Wildenhues* Ralf Wildenhues wrote on Sat, Nov 14, 2009 at 01:23:01PM CET:
<br>> With --separate and a way to print the current file name we could
<br>> replace the shell loop with two sed invocations. For example, if a
<br>> command `F' would print the file name of the currently open file or `-',
<br>> plus a newline, then one could use:
<br>[...]
<br><br>Proposed patch, still lacking tests. F is a bit unsymmetric to = wrt.
<br>missing --separate, not sure how to change that; take the name of the
<br>first input file only?
<br><br>Cheers,
<br>Ralf
<br><br>From 5131e412d337b225f9df3bb49adf62a72d6cf85e Mon Sep 17 00:00:00 2001
<br>From: Ralf Wildenhues <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26362363&i=0" target="_top" rel="nofollow">Ralf.Wildenhues@...</a>>
<br>Date: Sun, 15 Nov 2009 20:11:21 +0100
<br>Subject: [PATCH] New F command to print input file name
<br><br>2009-11-15 Ralf Wildenhues <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26362363&i=1" target="_top" rel="nofollow">Ralf.Wildenhues@...</a>>
<br><br> * doc/sed.texi (Extended Commands): Document F command.
<br> * doc/sed-in.texi: Regenerate.
<br> * sed/compile.c (compile_program): Accept 'F' if not --posix.
<br> * sed/execute.c (open_next_file): Always initialize in_file_name.
<br> (execute_program): Handle 'F'.
<br> * NEWS: Update.
<br>---
<br> NEWS | 2 ++
<br> doc/sed-in.texi | 7 +++++++
<br> doc/sed.texi | 7 +++++++
<br> sed/compile.c | 3 ++-
<br> sed/execute.c | 18 +++++++++++++-----
<br> 5 files changed, 31 insertions(+), 6 deletions(-)
<br><br>diff --git a/NEWS b/NEWS
<br>index b34758b..085e758 100644
<br>--- a/NEWS
<br>+++ b/NEWS
<br>@@ -4,6 +4,8 @@ Sed 4.2.2
<br>
<br> * -u also does unbuffered input, rather than unbuffered output only
<br>
<br>+* New command `F' to print current input file name
<br>+
<br> ----------------------------------------------------------------------------
<br> Sed 4.2.1
<br>
<br>diff --git a/doc/sed-in.texi b/doc/sed-in.texi
<br>index 0e64b23..eb48062 100644
<br>--- a/doc/sed-in.texi
<br>+++ b/doc/sed-in.texi
<br>@@ -1400,6 +1400,13 @@ lines, all but the last ending with a back-slash.
<br> In both cases, the results are undefined if the command to be
<br> executed contains a @sc{nul} character.
<br>
<br>+@item F
<br>+@findex F (File name) command
<br>+@cindex Printing file name
<br>+@cindex File name, printing
<br>+Print out the file name of the current input file (with a trailing
<br>+newline).
<br>+
<br> @item L @var{n}
<br> @findex L (fLow paragraphs) command
<br> @cindex Reformat pattern space
<br>diff --git a/doc/sed.texi b/doc/sed.texi
<br>index 66a926e..83d9b8c 100644
<br>--- a/doc/sed.texi
<br>+++ b/doc/sed.texi
<br>@@ -1401,6 +1401,13 @@ lines, all but the last ending with a back-slash.
<br> In both cases, the results are undefined if the command to be
<br> executed contains a @sc{nul} character.
<br>
<br>+@item F
<br>+@findex F (File name) command
<br>+@cindex Printing file name
<br>+@cindex File name, printing
<br>+Print out the file name of the current input file (with a trailing
<br>+newline).
<br>+
<br> @item L @var{n}
<br> @findex L (fLow paragraphs) command
<br> @cindex Reformat pattern space
<br>diff --git a/sed/compile.c b/sed/compile.c
<br>index c4a5250..9e9364d 100644
<br>--- a/sed/compile.c
<br>+++ b/sed/compile.c
<br>@@ -1097,7 +1097,7 @@ compile_program(vector)
<br> if (posixicity == POSIXLY_BASIC)
<br> switch (ch)
<br> {
<br>- case 'e': case 'v': case 'z': case 'L':
<br>+ case 'e': case 'F': case 'v': case 'z': case 'L':
<br> case 'Q': case 'T': case 'R': case 'W':
<br> bad_command(ch);
<br>
<br>@@ -1230,6 +1230,7 @@ compile_program(vector)
<br> case '=':
<br> case 'd':
<br> case 'D':
<br>+ case 'F':
<br> case 'g':
<br> case 'G':
<br> case 'h':
<br>diff --git a/sed/execute.c b/sed/execute.c
<br>index 28e520d..f9775ea 100644
<br>--- a/sed/execute.c
<br>+++ b/sed/execute.c
<br>@@ -714,6 +714,12 @@ open_next_file(name, input)
<br>
<br> input->read_fn = read_file_line;
<br>
<br>+ if (follow_symlinks)
<br>+ input->in_file_name = follow_symlink (name);
<br>+ else
<br>+ input->in_file_name = name;
<br>+
<br>+
<br> if (in_place_extension)
<br> {
<br> int input_fd;
<br>@@ -724,11 +730,6 @@ open_next_file(name, input)
<br> memset (&old_fscreatecon, 0, sizeof (old_fscreatecon));
<br> #endif
<br>
<br>- if (follow_symlinks)
<br>- input->in_file_name = follow_symlink (name);
<br>- else
<br>- input->in_file_name = name;
<br>-
<br> /* get the base name */
<br> tmpdir = ck_strdup(input->in_file_name);
<br> if ((p = strrchr(tmpdir, '/')))
<br>@@ -1758,6 +1759,13 @@ execute_program(vec, input)
<br> flush_output(output_file.fp);
<br> break;
<br>
<br>+ case 'F':
<br>+ output_missing_newline(&output_file);
<br>+ fprintf(output_file.fp, "%s\n",
<br>+ input->in_file_name);
<br>+ flush_output(output_file.fp);
<br>+ break;
<br>+
<br> default:
<br> panic("INTERNAL ERROR: Bad cmd %c", cur_cmd->cmd);
<br> }
<br>--
<br>1.6.5.1.31.gad12b
<br><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>tag:old.nabble.com,2006:post-26352544Re: at configure2009-11-14T10:30:59Z2009-11-14T10:30:59ZAharon Robbins> Aharon Robbins <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26352544&i=0" target="_top" rel="nofollow">arnold@...</a>> writes:
<br>>
<br>> > There should be a version of awk on any Unix-like OS
<br>>
<br>> Unless you are bootstrapping it :-) The GNU make sources include a
<br>> script so that you can build it without any make program. You still
<br>> need to be able to run configure, though.
<br>>
<br>> Andreas.
<br><br>Again, if you're bootstrapping, you're doing it from some kind
<br>of existing environment, and that one should have some sort of
<br>awk already there.
<br><br>Ah well.
<br><br>Thanks everyone.
<br><br>Arnold
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Utils---Bugs-f1828.html" embed="fixTarget[1828]" target="_top" >Gnu - Utils - Bugs</a></p>