* libintl: stubs or working functions? @ 2015-03-05 9:36 Рысь 2015-03-06 22:24 ` Rich Felker 0 siblings, 1 reply; 30+ messages in thread From: Рысь @ 2015-03-05 9:36 UTC (permalink / raw) To: musl I noticed that musl had got some gettext functions as a lightweight and more saner interface. However, I now have a couple questions about them as ordinary user. A bit of history. I had successfully built and used custom x86 musl based X11 root which uses both Xfbdev and Xorg servers on different machines. It is based on my previous musl on servers experience, just added X11 and major gui libraries on top of it. My root attracted a user because of it's small size to fit into budget netbook with very small disk size (about 4GB I think). The problem is that user does not speak (and understand) English at all, but he accepts my preferred program set which I preinstalled into root. So I faced a problem: I had built this root for myself and everywhere I did seen "--disable-nls" in configure scripts I used it. Now, I tried to rebuild untranslated programs, noticed that translation files (.po -> *.gmo) were created and installed in /local/share/locale/. However, trying to define LC_ALL and LANG environment variables as in most of glibc systems does not change anything. The programs still English translated. And a couple questions here: * Did I understand that right that I do not need GNU gettext anymore and I can use musl's interface for that? * Do I still need original GNU gettext to translate *.po's to *.gmo's? (I used gettext-tiny) * If musl can handle that, how I should configure it? Are environment variables work? Whole story and questions may be stupid if I misunderstand the purpose of those functions, so sorry. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-05 9:36 libintl: stubs or working functions? Рысь @ 2015-03-06 22:24 ` Rich Felker 2015-03-08 9:22 ` Рысь 0 siblings, 1 reply; 30+ messages in thread From: Rich Felker @ 2015-03-06 22:24 UTC (permalink / raw) To: musl On Thu, Mar 05, 2015 at 04:36:49PM +0700, Рысь wrote: > I noticed that musl had got some gettext functions as a lightweight and > more saner interface. However, I now have a couple questions about them > as ordinary user. > > A bit of history. > I had successfully built and used custom x86 musl based X11 root which > uses both Xfbdev and Xorg servers on different machines. It is based on > my previous musl on servers experience, just added X11 and major gui > libraries on top of it. > > My root attracted a user because of it's small size to fit into budget > netbook with very small disk size (about 4GB I think). The problem is > that user does not speak (and understand) English at all, but he accepts > my preferred program set which I preinstalled into root. > > So I faced a problem: I had built this root for myself and everywhere I > did seen "--disable-nls" in configure scripts I used it. Now, I tried > to rebuild untranslated programs, noticed that translation files (.po > -> *.gmo) were created and installed in /local/share/locale/. > > However, trying to define LC_ALL and LANG environment variables as in > most of glibc systems does not change anything. The programs still > English translated. > > And a couple questions here: > > * Did I understand that right that I do not need GNU gettext anymore and > I can use musl's interface for that? Yes, modulo some GNU software (coreutils for example) that probes for glibc/gnu-libintl internals at configure time and depends on poorly-designed and undocumented features (SYSDEP strings). These programs will not work without either GNU libintl or patching out the bad parts of configure and using a version of msgfmt that works around the need for SYSDEP strings. I believe the one from sabotage gettext-tiny does. > * Do I still need original GNU gettext to translate *.po's to *.gmo's? > (I used gettext-tiny) gettext-tiny is preferable as long as it works. As mentioned above it even works around the SYSDEP strings issue. > * If musl can handle that, how I should configure it? Are environment > variables work? For translations of musl itself (which don't exist yet) the MUSL_LOCPATH environment variable needs to be set. But most programs that use gettext hard-code their own pathnames for passing to bindtextdomain, and this is the documented correct way to use the API. So there is no default gettext path in musl. > Whole story and questions may be stupid if I misunderstand the purpose > of those functions, so sorry. Not stupid at all. Hope the above helps. Let me know if you have any more questions. If you find that lack of translations for the messages from musl itself (errno strings, etc.) is a problem, I can try to help you with producing a locale file for musl. I want to get a musl-locales project started and it would be nice to have a trial run-through. Rich ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-06 22:24 ` Rich Felker @ 2015-03-08 9:22 ` Рысь 2015-03-09 0:56 ` Rich Felker 0 siblings, 1 reply; 30+ messages in thread From: Рысь @ 2015-03-08 9:22 UTC (permalink / raw) To: musl On Fri, 6 Mar 2015 17:24:15 -0500 Rich Felker <dalias@libc.org> wrote: > On Thu, Mar 05, 2015 at 04:36:49PM +0700, Рысь wrote: > > I noticed that musl had got some gettext functions as a lightweight > > and more saner interface. However, I now have a couple questions > > about them as ordinary user. > > > > A bit of history. > > I had successfully built and used custom x86 musl based X11 root > > which uses both Xfbdev and Xorg servers on different machines. It > > is based on my previous musl on servers experience, just added X11 > > and major gui libraries on top of it. > > > > My root attracted a user because of it's small size to fit into > > budget netbook with very small disk size (about 4GB I think). The > > problem is that user does not speak (and understand) English at > > all, but he accepts my preferred program set which I preinstalled > > into root. > > > > So I faced a problem: I had built this root for myself and > > everywhere I did seen "--disable-nls" in configure scripts I used > > it. Now, I tried to rebuild untranslated programs, noticed that > > translation files (.po -> *.gmo) were created and installed > > in /local/share/locale/. > > > > However, trying to define LC_ALL and LANG environment variables as > > in most of glibc systems does not change anything. The programs > > still English translated. > > > > And a couple questions here: > > > > * Did I understand that right that I do not need GNU gettext > > anymore and I can use musl's interface for that? > > Yes, modulo some GNU software (coreutils for example) that probes for > glibc/gnu-libintl internals at configure time and depends on > poorly-designed and undocumented features (SYSDEP strings). These > programs will not work without either GNU libintl or patching out the > bad parts of configure and using a version of msgfmt that works around > the need for SYSDEP strings. I believe the one from sabotage > gettext-tiny does. > > > * Do I still need original GNU gettext to translate *.po's to > > *.gmo's? (I used gettext-tiny) > > gettext-tiny is preferable as long as it works. As mentioned above it > even works around the SYSDEP strings issue. > > > * If musl can handle that, how I should configure it? Are > > environment variables work? > > For translations of musl itself (which don't exist yet) the > MUSL_LOCPATH environment variable needs to be set. But most programs > that use gettext hard-code their own pathnames for passing to > bindtextdomain, and this is the documented correct way to use the API. > So there is no default gettext path in musl. Interesting. Well, than I need to investigate more. strace does not show any tryings to find or even to poke at locale data installed by application. nm output from binary does not show any "textd" pattern. config.log then says NLS is supported via external libintl.a (did I do a right thing by creating an empty libintl.a file to redirect libintl functions to libc at link time?) Probably application thinks it have found libintl, but for some reason does not enable it's code. > > > Whole story and questions may be stupid if I misunderstand the > > purpose of those functions, so sorry. > > Not stupid at all. Hope the above helps. Let me know if you have any > more questions. Okay. Sorry, as for now I did not read locale libc code fully and quite do not understand it (I am in process of rebuilding my primary desktop to move it to my mentioned musl root, that's quite of time consuming). Example application of question is email client claws-mail (I even use it now to send an email to you, so I can test it). On my system it's locale data is stored into /local/share/locale/ru/LC_MESSAGES/claws-mail.mo. On typical glibc system I needed to set LC_ALL and LANG environment variables to something like "ru_RU.UTF-8". What I should do with musl for _not translating musl_, but for (probably) NLS-enabled external application? And what symbols should I see in nm output for any application to verify it actually uses NLS? > > If you find that lack of translations for the messages from musl > itself (errno strings, etc.) is a problem, I can try to help you with > producing a locale file for musl. I want to get a musl-locales project > started and it would be nice to have a trial run-through. > > Rich Thanks I will happy to at least try! You only should prepare exact instructions and needed software so I can start work quickly :) If I will catch time right I will try to reach you on IRC at least within next week. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-08 9:22 ` Рысь @ 2015-03-09 0:56 ` Rich Felker 2015-03-15 12:33 ` Рысь 0 siblings, 1 reply; 30+ messages in thread From: Rich Felker @ 2015-03-09 0:56 UTC (permalink / raw) To: musl On Sun, Mar 08, 2015 at 04:22:49PM +0700, Рысь wrote: > > > * If musl can handle that, how I should configure it? Are > > > environment variables work? > > > > For translations of musl itself (which don't exist yet) the > > MUSL_LOCPATH environment variable needs to be set. But most programs > > that use gettext hard-code their own pathnames for passing to > > bindtextdomain, and this is the documented correct way to use the API. > > So there is no default gettext path in musl. > > Interesting. Well, than I need to investigate more. strace does not > show any tryings to find or even to poke at locale data installed by > application. nm output from binary does not show any "textd" pattern. > config.log then says NLS is supported via external libintl.a (did I do > a right thing by creating an empty libintl.a file to redirect libintl > functions to libc at link time?) I don't think this should be needed; programs I've seen that use gettext first see if it's available in libc without any additional -l. > Probably application thinks it have found libintl, but for some reason > does not enable it's code. Perhaps. > > > Whole story and questions may be stupid if I misunderstand the > > > purpose of those functions, so sorry. > > > > Not stupid at all. Hope the above helps. Let me know if you have any > > more questions. > > Okay. Sorry, as for now I did not read locale libc code fully and quite > do not understand it (I am in process of rebuilding my primary desktop > to move it to my mentioned musl root, that's quite of time consuming). > > Example application of question is email client claws-mail (I even use > it now to send an email to you, so I can test it). On my system it's > locale data is stored > into /local/share/locale/ru/LC_MESSAGES/claws-mail.mo. On typical glibc > system I needed to set LC_ALL and LANG environment variables to > something like "ru_RU.UTF-8". What I should do with musl for _not > translating musl_, but for (probably) NLS-enabled external application? Have at least LC_MESSAGES set to "ru". Or if you want to be able to use "ru_RU", make sure the latter exists in /local/share/locale and that it's a symlink to "ru". > And what symbols should I see in nm output for any application to > verify it actually uses NLS? bindtextdomain and something containing gettext (probably dgettext or dcgettext). > > If you find that lack of translations for the messages from musl > > itself (errno strings, etc.) is a problem, I can try to help you with > > producing a locale file for musl. I want to get a musl-locales project > > started and it would be nice to have a trial run-through. > > Thanks I will happy to at least try! You only should prepare exact > instructions and needed software so I can start work quickly :) > > If I will catch time right I will try to reach you on IRC at least > within next week. OK. Rich ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-09 0:56 ` Rich Felker @ 2015-03-15 12:33 ` Рысь 2015-03-15 23:54 ` Rich Felker 0 siblings, 1 reply; 30+ messages in thread From: Рысь @ 2015-03-15 12:33 UTC (permalink / raw) To: musl On Sun, 8 Mar 2015 20:56:36 -0400 Rich Felker <dalias@libc.org> wrote: > On Sun, Mar 08, 2015 at 04:22:49PM +0700, Рысь wrote: > > > > * If musl can handle that, how I should configure it? Are > > > > environment variables work? > > > > > > For translations of musl itself (which don't exist yet) the > > > MUSL_LOCPATH environment variable needs to be set. But most > > > programs that use gettext hard-code their own pathnames for > > > passing to bindtextdomain, and this is the documented correct way > > > to use the API. So there is no default gettext path in musl. > > > > Interesting. Well, than I need to investigate more. strace does not > > show any tryings to find or even to poke at locale data installed by > > application. nm output from binary does not show any "textd" > > pattern. config.log then says NLS is supported via external > > libintl.a (did I do a right thing by creating an empty libintl.a > > file to redirect libintl functions to libc at link time?) > > I don't think this should be needed; programs I've seen that use > gettext first see if it's available in libc without any additional -l. > > > Probably application thinks it have found libintl, but for some > > reason does not enable it's code. > > Perhaps. > > > > > Whole story and questions may be stupid if I misunderstand the > > > > purpose of those functions, so sorry. > > > > > > Not stupid at all. Hope the above helps. Let me know if you have > > > any more questions. > > > > Okay. Sorry, as for now I did not read locale libc code fully and > > quite do not understand it (I am in process of rebuilding my > > primary desktop to move it to my mentioned musl root, that's quite > > of time consuming). > > > > Example application of question is email client claws-mail (I even > > use it now to send an email to you, so I can test it). On my system > > it's locale data is stored > > into /local/share/locale/ru/LC_MESSAGES/claws-mail.mo. On typical > > glibc system I needed to set LC_ALL and LANG environment variables > > to something like "ru_RU.UTF-8". What I should do with musl for _not > > translating musl_, but for (probably) NLS-enabled external > > application? > > Have at least LC_MESSAGES set to "ru". Or if you want to be able to > use "ru_RU", make sure the latter exists in /local/share/locale and > that it's a symlink to "ru". > > > And what symbols should I see in nm output for any application to > > verify it actually uses NLS? > > bindtextdomain and something containing gettext (probably dgettext or > dcgettext). > > > > If you find that lack of translations for the messages from musl > > > itself (errno strings, etc.) is a problem, I can try to help you > > > with producing a locale file for musl. I want to get a > > > musl-locales project started and it would be nice to have a trial > > > run-through. > > > > Thanks I will happy to at least try! You only should prepare exact > > instructions and needed software so I can start work quickly :) > > > > If I will catch time right I will try to reach you on IRC at least > > within next week. > > OK. > > Rich Ok, for now I am probably stuck with this one, it needs much of reading from endless strace logs for various gtkware. I got it to include *gettext syms and now gtk stack calls them, but that's a dead end: even if I set all LC_/LANG properly I still get English and my debugging musl which have locale functions with inserted printfs at beginning show only setlocale(0, "") and that's all. Only few called with proper arguments. I see .mo's from proper path (containing name of desired locale, thus = "*/ru/*") are mmaped. As for now I have no much time to test it (likely I will continue on this one in next month or so), so I only want to resolve one issue which still stays: is it permitted to change strftime in a way that "%x" will return NOT American date with month in beginning, but preferred date like "%d.%m.%Y" or similar? Will not it break any existing apps? Thanks. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-15 12:33 ` Рысь @ 2015-03-15 23:54 ` Rich Felker 2015-03-16 4:18 ` Рысь 2015-03-16 9:27 ` Szabolcs Nagy 0 siblings, 2 replies; 30+ messages in thread From: Rich Felker @ 2015-03-15 23:54 UTC (permalink / raw) To: musl On Sun, Mar 15, 2015 at 07:33:39PM +0700, Рысь wrote: > Ok, for now I am probably stuck with this one, it needs much of reading > from endless strace logs for various gtkware. I got it to include > *gettext syms and now gtk stack calls them, but that's a dead end: even > if I set all LC_/LANG properly I still get English and my debugging > musl which have locale functions with inserted printfs at beginning > show only setlocale(0, "") and that's all. Only few called with proper > arguments. I see .mo's from proper path (containing name of desired > locale, thus = "*/ru/*") are mmaped. > > As for now I have no much time to test it (likely I will continue on > this one in next month or so), so I only want to resolve one issue which > still stays: is it permitted to change strftime in a way that "%x" will > return NOT American date with month in beginning, but preferred date > like "%d.%m.%Y" or similar? Will not it break any existing apps? I'm not aware one way or the other whether it would break existing applications for strftime to format %x in a non-conforming way for the C locale. It's certainly possible that this could break apps, since the C standard specifies an exact date/time format for the C locale, but it's probably not extremely likely. To achieve this with a locale (which should not break anything), you would just need to make a po file that maps the string "%m/%d/%y" to "%d.%m.%Y" or similar, build this into a .mo file named "ru_RU" (with no extension), and drop it into a directory in $MUSL_LOCPATH (which you should set). Then LC_DATE=ru_RU would give your desired formatting. This ru_RU locale file could also be extended with translations for error messages, mappings for other date/time formats, etc. Rich ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-15 23:54 ` Rich Felker @ 2015-03-16 4:18 ` Рысь 2015-03-16 13:04 ` Szabolcs Nagy 2015-03-16 13:41 ` Szabolcs Nagy 2015-03-16 9:27 ` Szabolcs Nagy 1 sibling, 2 replies; 30+ messages in thread From: Рысь @ 2015-03-16 4:18 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 3107 bytes --] On Sun, 15 Mar 2015 19:54:18 -0400 Rich Felker <dalias@libc.org> wrote: > On Sun, Mar 15, 2015 at 07:33:39PM +0700, Рысь wrote: > > Ok, for now I am probably stuck with this one, it needs much of > > reading from endless strace logs for various gtkware. I got it to > > include *gettext syms and now gtk stack calls them, but that's a > > dead end: even if I set all LC_/LANG properly I still get English > > and my debugging musl which have locale functions with inserted > > printfs at beginning show only setlocale(0, "") and that's all. > > Only few called with proper arguments. I see .mo's from proper path > > (containing name of desired locale, thus = "*/ru/*") are mmaped. > > > > As for now I have no much time to test it (likely I will continue on > > this one in next month or so), so I only want to resolve one issue > > which still stays: is it permitted to change strftime in a way that > > "%x" will return NOT American date with month in beginning, but > > preferred date like "%d.%m.%Y" or similar? Will not it break any > > existing apps? > > I'm not aware one way or the other whether it would break existing > applications for strftime to format %x in a non-conforming way for the > C locale. It's certainly possible that this could break apps, since > the C standard specifies an exact date/time format for the C locale, > but it's probably not extremely likely. > > To achieve this with a locale (which should not break anything), you > would just need to make a po file that maps the string "%m/%d/%y" to > "%d.%m.%Y" or similar, build this into a .mo file named "ru_RU" (with > no extension), and drop it into a directory in $MUSL_LOCPATH (which > you should set). Then LC_DATE=ru_RU would give your desired > formatting. > > This ru_RU locale file could also be extended with translations for > error messages, mappings for other date/time formats, etc. > > Rich Hm, I tried this now but without success :-( I searched for po file layout and I assume this is something like this: % cat ru_RU.po # strftime %x msgid "%m/%d/%y" msgstr "%d.%m.%Y" then, I do translate it into .mo file without extension: % mkdir ru % msgfmt ru_RU.po -o ru/ru_RU % file ru/ru_RU ru/ru_RU: GNU-format message catalog data % strings -a ru/ru_RU %m/%d/%y %d.%m.%Y I have this test program: % cat dt.c #include <time.h> #include <stdio.h> int main(void) { char x[32]; struct tm *tm; time_t t; t = time(NULL); tm = localtime(&t); strftime(x, sizeof(x), "%x", tm); printf("%s\n", x); return 0; } (compile it as usual) and not, with MUSL_LOCPATH=$(pwd)/ru LC_DATE=ru_RU ./dt, I still see 03/16/15. Not even with LC_TIME and LC_ALL/LANG pair. I attach strace log, but it probably useless, it only shows no files are included. Same with musl from git (I currently on musl 1.1.4). Am I completely messed something? [-- Attachment #2: dt.log --] [-- Type: application/octet-stream, Size: 752 bytes --] execve("./dt", ["./dt"], [/* 22 vars */]) = 0 set_thread_area({entry_number:-1 -> 12, base_addr:0xf778faa4, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 set_tid_address(0xf778fabc) = 31519 clock_gettime(CLOCK_REALTIME, {1426479368, 263386372}) = 0 open("/etc/localtime", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_CLOEXEC) = 3 fstat64(3, {st_mode=0171044, st_size=1, ...}) = 0 mmap2() = 0xf76e4000 close(3) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0xff9198e4) = -1 ENOTTY (Not a tty) writev(1, [{"03/16/15", 8}, {"\n", 1}], 203/16/15 ) = 9 exit_group(0) = ? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-16 4:18 ` Рысь @ 2015-03-16 13:04 ` Szabolcs Nagy 2015-03-16 13:35 ` Szabolcs Nagy 2015-03-16 13:41 ` Szabolcs Nagy 1 sibling, 1 reply; 30+ messages in thread From: Szabolcs Nagy @ 2015-03-16 13:04 UTC (permalink / raw) To: musl * ???????? <lynx@sibserver.ru> [2015-03-16 11:18:46 +0700]: > On Sun, 15 Mar 2015 19:54:18 -0400 > Rich Felker <dalias@libc.org> wrote: > > > > To achieve this with a locale (which should not break anything), you > > would just need to make a po file that maps the string "%m/%d/%y" to > > "%d.%m.%Y" or similar, build this into a .mo file named "ru_RU" (with > > no extension), and drop it into a directory in $MUSL_LOCPATH (which > > you should set). Then LC_DATE=ru_RU would give your desired > > formatting. > > > > This ru_RU locale file could also be extended with translations for > > error messages, mappings for other date/time formats, etc. > > > > Rich > > Hm, I tried this now but without success :-( > > I searched for po file layout and I assume this is something like this: > > % cat ru_RU.po > > # strftime %x > msgid "%m/%d/%y" > msgstr "%d.%m.%Y" > > then, I do translate it into .mo file without extension: i think you will have to provide translatation for the c_time string in langinfo.c: http://git.musl-libc.org/cgit/musl/tree/src/locale/langinfo.c i tried xgettext -a langinfo.c but it failed to extract the \0 correctly, you need to concatenate the stringliterals and preserve all the \0 (in theory the format can handle embedded \0, not sure if all the gettext tools can deal with it) so currently this is not very translator friendly.. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-16 13:04 ` Szabolcs Nagy @ 2015-03-16 13:35 ` Szabolcs Nagy 0 siblings, 0 replies; 30+ messages in thread From: Szabolcs Nagy @ 2015-03-16 13:35 UTC (permalink / raw) To: musl * Szabolcs Nagy <nsz@port70.net> [2015-03-16 14:04:59 +0100]: > i think you will have to provide translatation for > the c_time string in langinfo.c: > > http://git.musl-libc.org/cgit/musl/tree/src/locale/langinfo.c > sorry LCTRANS is called on the individual string fragments there, not on the entire c_time. so translating "%m/%d/%y" should work. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-16 4:18 ` Рысь 2015-03-16 13:04 ` Szabolcs Nagy @ 2015-03-16 13:41 ` Szabolcs Nagy 2015-03-17 1:40 ` Рысь 1 sibling, 1 reply; 30+ messages in thread From: Szabolcs Nagy @ 2015-03-16 13:41 UTC (permalink / raw) To: musl * ???????? <lynx@sibserver.ru> [2015-03-16 11:18:46 +0700]: > I have this test program: > > % cat dt.c > #include <time.h> > #include <stdio.h> > > int main(void) > { > char x[32]; > struct tm *tm; > time_t t; > > t = time(NULL); > tm = localtime(&t); > strftime(x, sizeof(x), "%x", tm); > printf("%s\n", x); > > return 0; > } > i think you need to call setlocale(LC_ALL, "") ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-16 13:41 ` Szabolcs Nagy @ 2015-03-17 1:40 ` Рысь 2015-03-17 2:01 ` Rich Felker 0 siblings, 1 reply; 30+ messages in thread From: Рысь @ 2015-03-17 1:40 UTC (permalink / raw) To: musl; +Cc: Rich Felker On Mon, 16 Mar 2015 14:41:56 +0100 Szabolcs Nagy <nsz@port70.net> wrote: > * ???????? <lynx@sibserver.ru> [2015-03-16 11:18:46 +0700]: > > I have this test program: > > > > % cat > > dt.c #include <time.h> > > #include <stdio.h> > > > > int main(void) > > { > > char x[32]; > > struct tm *tm; > > time_t t; > > > > t = time(NULL); > > tm = localtime(&t); > > strftime(x, sizeof(x), "%x", tm); > > printf("%s\n", x); > > > > return 0; > > } > > > > i think you need to call setlocale(LC_ALL, "") Thanks! Now it worked as needed! Rich: from this point I probably do understand how to translate certain strings in C library, can you provide more info about what should be translated? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-17 1:40 ` Рысь @ 2015-03-17 2:01 ` Rich Felker 2015-03-17 6:59 ` Рысь 0 siblings, 1 reply; 30+ messages in thread From: Rich Felker @ 2015-03-17 2:01 UTC (permalink / raw) To: musl On Tue, Mar 17, 2015 at 08:40:04AM +0700, Рысь wrote: > On Mon, 16 Mar 2015 14:41:56 +0100 > Szabolcs Nagy <nsz@port70.net> wrote: > > > * ???????? <lynx@sibserver.ru> [2015-03-16 11:18:46 +0700]: > > > I have this test program: > > > > > > % cat > > > dt.c #include <time.h> > > > #include <stdio.h> > > > > > > int main(void) > > > { > > > char x[32]; > > > struct tm *tm; > > > time_t t; > > > > > > t = time(NULL); > > > tm = localtime(&t); > > > strftime(x, sizeof(x), "%x", tm); > > > printf("%s\n", x); > > > > > > return 0; > > > } > > > > > > > i think you need to call setlocale(LC_ALL, "") > > Thanks! Now it worked as needed! Great! > Rich: from this point I probably do understand how to translate certain > strings in C library, can you provide more info about what should be > translated? LC_TIME: Day and month names, am/pm, and some locale-specific formats. See src/locale/langinfo.c for a list. LC_MONETARY: Not supported yet. LC_MESSAGES: Error strings (src/errno/__strerror.h), signal strings (src/string/strsignal.c), and the yes/no regex/strings in src/locale/langinfo.c. Maybe some other things too. Eventually dynamic linker related messages and maybe some other things will be added. LC_NUMERIC: Nothing. LC_CTYPE: Nothing. LC_COLLATE: Not supported yet. Rich ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-17 2:01 ` Rich Felker @ 2015-03-17 6:59 ` Рысь 2015-03-17 15:02 ` Szabolcs Nagy 2015-03-24 3:59 ` Рысь 0 siblings, 2 replies; 30+ messages in thread From: Рысь @ 2015-03-17 6:59 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 2145 bytes --] On Mon, 16 Mar 2015 22:01:19 -0400 Rich Felker <dalias@libc.org> wrote: > On Tue, Mar 17, 2015 at 08:40:04AM +0700, Рысь wrote: > > On Mon, 16 Mar 2015 14:41:56 +0100 > > Szabolcs Nagy <nsz@port70.net> wrote: > > > > > * ???????? <lynx@sibserver.ru> [2015-03-16 11:18:46 +0700]: > > > > I have this test program: > > > > > > > > % cat > > > > dt.c #include <time.h> > > > > #include <stdio.h> > > > > > > > > int main(void) > > > > { > > > > char x[32]; > > > > struct tm *tm; > > > > time_t t; > > > > > > > > t = time(NULL); > > > > tm = localtime(&t); > > > > strftime(x, sizeof(x), "%x", tm); > > > > printf("%s\n", x); > > > > > > > > return 0; > > > > } > > > > > > > > > > i think you need to call setlocale(LC_ALL, "") > > > > Thanks! Now it worked as needed! > > Great! > > > Rich: from this point I probably do understand how to translate > > certain strings in C library, can you provide more info about what > > should be translated? > > LC_TIME: Day and month names, am/pm, and some locale-specific formats. > See src/locale/langinfo.c for a list. > > LC_MONETARY: Not supported yet. > > LC_MESSAGES: Error strings (src/errno/__strerror.h), signal strings > (src/string/strsignal.c), and the yes/no regex/strings in > src/locale/langinfo.c. Maybe some other things too. Eventually dynamic > linker related messages and maybe some other things will be added. > > LC_NUMERIC: Nothing. > > LC_CTYPE: Nothing. > > LC_COLLATE: Not supported yet. > > Rich Attached is my draft of translated strings you mentioned to Russian. Some strings I borrowed from glibc, but only few of them (things like "Broken pipe" and similar). Certain translations may be inaccurate, but mostly if I did not know context I did an additional quick research by grepping man pages. I think this should be additionally reviewed by russian subscribers. File compiles with msgfmt but I did not tested it. I will do when I will establish a locale kvm machine to test and finally fix my locale issue. Let me know if additional places in libc need to be translated. [-- Attachment #2: ru_RU.po --] [-- Type: application/octet-stream, Size: 11595 bytes --] # src/locale/langinfo.c # week day names msgid "Sun" msgstr "Вск" msgid "Mon" msgstr "Пн" msgid "Tue" msgstr "Вт" msgid "Wed" msgstr "Ср" msgid "Thu" msgstr "Чт" msgid "Fri" msgstr "Пт" msgid "Sat" msgstr "Сб" msgid "Sunday" msgstr "Воскресенье" msgid "Monday" msgstr "Понедельник" msgid "Tuesday" msgstr "Вторник" msgid "Wednesday" msgstr "Среда" msgid "Thursday" msgstr "Четверг" msgid "Friday" msgstr "Пятница" msgid "Saturday" msgstr "Суббота" # month names msgid "Jan" msgstr "Янв" msgid "Feb" msgstr "Фев" msgid "Mar" msgstr "Мар" msgid "Apr" msgstr "Апр" msgid "May" msgstr "Май" msgid "Jun" msgstr "Июн" msgid "Jul" msgstr "Июл" msgid "Aug" msgstr "Авг" msgid "Sep" msgstr "Сен" msgid "Oct" msgstr "Окт" msgid "Nov" msgstr "Ноя" msgid "Dec" msgstr "Дек" msgid "January" msgstr "Январь" msgid "February" msgstr "Февраль" msgid "March" msgstr "Март" msgid "April" msgstr "Апрель" msgid "May" msgstr "Май" msgid "June" msgstr "Июнь" msgid "July" msgstr "Июль" msgid "August" msgstr "Август" msgid "September" msgstr "Сентябрь" msgid "October" msgstr "Октябрь" msgid "November" msgstr "Ноябрь" msgid "December" msgstr "Декабрь" # strftime localization msgid "%m/%d/%y" msgstr "%d.%m.%Y" msgid "%I:%M:%S %p" msgstr "%H:%M:%S" # yes/no strings msgid "^[yY]" msgstr "^[дД]" msgid "^[nN]" msgstr "^[нН]" msgid "yes" msgstr "да" msgid "no" msgstr "нет" # src/errno/__strerror.h: errno strings msgid "Illegal byte sequence" msgstr "Недопустимая последовательность" msgid "Domain error" msgstr "Значение вне области функции" msgid "Result not representable" msgstr "Значение за пределами допустимых границ" msgid "Not a tty" msgstr "Не телетайп" msgid "Permission denied" msgstr "Отказано в доступе" msgid "Operation not permitted" msgstr "Операция не позволяется" msgid "No such file or directory" msgstr "Нет такого файла или каталога" msgid "No such process" msgstr "Нет такого процесса" msgid "File exists" msgstr "Файл существует" msgid "Value too large for data type" msgstr "Значение выходит за рамки типа" msgid "No space left on device" msgstr "На устройстве кончилось место" msgid "Out of memory" msgstr "Нет свободной памяти" msgid "Resource busy" msgstr "Ресурс занят" msgid "Interrupted system call" msgstr "Системный вызов прерван" msgid "Resource temporarily unavailable" msgstr "Ресурс временно недоступен" msgid "Invalid seek" msgstr "Неверное позиционирование" msgid "Cross-device link" msgstr "Перекрёстная ссылка между устройствами" msgid "Read-only file system" msgstr "Файловая система доступна только для чтения" msgid "Directory not empty" msgstr "Каталог не пуст" msgid "Connection reset by peer" msgstr "Соединение разорвано удалённой стороной" msgid "Operation timed out" msgstr "Истекло время для запроса" msgid "Connection refused" msgstr "Соединение отвергнуто" msgid "Host is down" msgstr "Удалённая система не отвечает" msgid "Host is unreachable" msgstr "Удалённая система недоступна" msgid "Address in use" msgstr "Адрес уже используется" msgid "Broken pipe" msgstr "Обрыв канала" msgid "I/O error" msgstr "Ошибка ввода/вывода" msgid "No such device or address" msgstr "Нет такого устройства или адреса" msgid "Block device required" msgstr "Нужно блочное устройство" msgid "No such device" msgstr "Нет такого устройства" msgid "Not a directory" msgstr "Это не каталог" msgid "Is a directory" msgstr "Это каталог" msgid "Text file busy" msgstr "Файл занят" msgid "Exec format error" msgstr "Не исполняемый формат" msgid "Invalid argument" msgstr "Неверный параметр" msgid "Argument list too long" msgstr "Список параметров слишком длинный" msgid "Symbolic link loop" msgstr "Циклическая символьная ссылка" msgid "Filename too long" msgstr "Слишком длинное имя файла" msgid "Too many open files in system" msgstr "Открыто слишком много файлов в системе" msgid "No file descriptors available" msgstr "Больше нет дескрипторов файлов" msgid "Bad file descriptor" msgstr "Неправильный дескриптор файла" msgid "No child process" msgstr "Нет дочерних процессов" msgid "Bad address" msgstr "Неправильный адрес в памяти" msgid "File too large" msgstr "Файл слишком длинный" msgid "Too many links" msgstr "Слишком много связей" msgid "No locks available" msgstr "Нет доступных блокировок" msgid "Resource deadlock would occur" msgstr "Произойдёт взаимная блокировка" msgid "State not recoverable" msgstr "Состояние нельзя восстановить" msgid "Previous owner died" msgstr "Предыдущий процесс завершился" msgid "Operation canceled" msgstr "Операция отменена" msgid "Function not implemented" msgstr "Функциональность не реализована" msgid "No message of desired type" msgstr "Нет сообщения нужного типа" msgid "Identifier removed" msgstr "Идентификатор удалён" msgid "Device not a stream" msgstr "Не поточное устройство" msgid "No data available" msgstr "Нет данных" msgid "Device timeout" msgstr "Таймаут ожидания устройства" msgid "Out of streams resources" msgstr "Нет свободных поточных ресурсов" msgid "Link has been severed" msgstr "Соединение разорвано" msgid "Protocol error" msgstr "Ошибка протокола" msgid "Bad message" msgstr "Неправильное сообщение" msgid "File descriptor in bad state" msgstr "Дескриптор файла испорчен" msgid "Not a socket" msgstr "Это не сокет" msgid "Destination address required" msgstr "Требуется адрес назначения" msgid "Message too large" msgstr "Сообщение слишком длинное" msgid "Protocol wrong type for socket" msgstr "Неправильный протокол для сокета" msgid "Protocol not available" msgstr "Протокол недоступен" msgid "Protocol not supported" msgstr "Протокол не поддерживается" msgid "Socket type not supported" msgstr "Тип сокета не поддерживается" msgid "Not supported" msgstr "Не поддерживается" msgid "Protocol family not supported" msgstr "Семейство протоколов не поддерживается" msgid "Address family not supported by protocol" msgstr "Семейство адресов не поддерживается протоколом" msgid "Address not available" msgstr "Адрес не доступен" msgid "Network is down" msgstr "Сеть выключена" msgid "Network unreachable" msgstr "Сеть недоступна" msgid "Connection reset by network" msgstr "Соединение разорвано сетью" msgid "Connection aborted" msgstr "Соединение отменено" msgid "No buffer space available" msgstr "Недостаточно промежуточного пространства" msgid "Socket is connected" msgstr "Сокет уже соединён" msgid "Socket not connected" msgstr "Сокет не соединён" msgid "Cannot send after socket shutdown" msgstr "Отправка невозможна при выключенном сокете" msgid "Operation already in progress" msgstr "Операция уже производится" msgid "Operation in progress" msgstr "Операция в процессе" msgid "Stale file handle" msgstr "Зависший дескриптор файла" msgid "Remote I/O error" msgstr "Удалённая ошибка ввода/вывода" msgid "Quota exceeded" msgstr "Квота исчерпана" msgid "No medium found" msgstr "Не найден носитель" msgid "Wrong medium type" msgstr "Неправильный тип носителя" msgid "No error information" msgstr "Нет информации об ошибке" # src/string/strsignal.c: signal names msgid "Unknown signal" msgstr "Неизвестный сигнал" msgid "Hangup" msgstr "Обрыв терминала" msgid "Interrupt" msgstr "Прервано" msgid "Quit" msgstr "Выход" msgid "Illegal instruction" msgstr "Недопустимая инструкция" msgid "Trace/breakpoint trap" msgstr "Отладочная точка" msgid "Aborted" msgstr "Прекращёно" msgid "Bus error" msgstr "Ошибка шины" msgid "Arithmetic exception" msgstr "Исключение в операции с плавающей запятой" msgid "Killed" msgstr "Убито" msgid "User defined signal 1" msgstr "Пользовательский сигнал №1" msgid "Segmentation fault" msgstr "Ошибка сегментирования" msgid "User defined signal 2" msgstr "Пользовательский сигнал №2" msgid "Broken pipe" msgstr "Обрыв канала" msgid "Alarm clock" msgstr "Сигнал таймера" msgid "Terminated" msgstr "Завершено" msgid "Stack fault" msgstr "Ошибка стека" msgid "Child process status" msgstr "Состояние дочернего процесса" msgid "Continued" msgstr "Продолжен" msgid "Stopped (signal)" msgstr "Остановлен (по сигналу)" msgid "Stopped" msgstr "Остановлен" msgid "Stopped (tty input)" msgstr "Остановлен (по вводу с терминала)" msgid "Stopped (tty output)" msgstr "Остановлен (по выводу в терминал)" msgid "Urgent I/O condition" msgstr "Есть срочные данные ввода/вывода" msgid "CPU time limit exceeded" msgstr "Исчерпан лимит на процессорное время" msgid "File size limit exceeded" msgstr "Исчерпан лимит на размер файла" msgid "Virtual timer expired" msgstr "Истёк виртуальный таймер" msgid "Profiling timer expired" msgstr "Истёк таймер профилирования" msgid "Window changed" msgstr "Изменилось окно терминала" msgid "I/O possible" msgstr "Ввод/вывод стал возможен" msgid "Power failure" msgstr "Система перешла на резервное питание" msgid "Bad system call" msgstr "Неправильный системный вызов" ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-17 6:59 ` Рысь @ 2015-03-17 15:02 ` Szabolcs Nagy 2015-03-17 15:38 ` Rich Felker 2015-03-18 7:15 ` Рысь 2015-03-24 3:59 ` Рысь 1 sibling, 2 replies; 30+ messages in thread From: Szabolcs Nagy @ 2015-03-17 15:02 UTC (permalink / raw) To: musl * ???????? <lynx@sibserver.ru> [2015-03-17 13:59:16 +0700]: > Attached is my draft of translated strings you mentioned to Russian. > Some strings I borrowed from glibc, but only few of them (things like > "Broken pipe" and similar). Certain translations may be inaccurate, but > mostly if I did not know context I did an additional quick research by > grepping man pages. I think this should be additionally reviewed by > russian subscribers. > i'm a bit worried about translated error messages, it's always a pain to understand bugreports with those can we include the enum name? like msgid "Permission denied" msgstr "asdf@# lkjk^& (EPERM)" ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-17 15:02 ` Szabolcs Nagy @ 2015-03-17 15:38 ` Rich Felker 2015-03-17 18:51 ` Wermut 2015-03-18 14:10 ` u-wsnj 2015-03-18 7:15 ` Рысь 1 sibling, 2 replies; 30+ messages in thread From: Rich Felker @ 2015-03-17 15:38 UTC (permalink / raw) To: musl On Tue, Mar 17, 2015 at 04:02:34PM +0100, Szabolcs Nagy wrote: > * ???????? <lynx@sibserver.ru> [2015-03-17 13:59:16 +0700]: > > Attached is my draft of translated strings you mentioned to Russian. > > Some strings I borrowed from glibc, but only few of them (things like > > "Broken pipe" and similar). Certain translations may be inaccurate, but > > mostly if I did not know context I did an additional quick research by > > grepping man pages. I think this should be additionally reviewed by > > russian subscribers. > > > > i'm a bit worried about translated error messages, it's always a pain > to understand bugreports with those > > can we include the enum name? > like > > msgid "Permission denied" > msgstr "asdf@# lkjk^& (EPERM)" I'm a bit undecided on this. It's reasonable to ask people reporting bugs to set their locale temporarily to something the project maintainers understand (typically English). It's also pretty easy to grep the .po files or use Google Translate to figure out what the message says. If users with a non-English locale would find those kind of messages helpful and non-obtrusive (is latin text in the middle of non-latin obtrusive? perhaps, depending on font?), I'm not opposed to having them, but I don't think they should be added against the desire of most users out of an interest in making it easier to interpret bug reports for us or for other upstreams. Rich ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-17 15:38 ` Rich Felker @ 2015-03-17 18:51 ` Wermut 2015-03-18 14:10 ` u-wsnj 1 sibling, 0 replies; 30+ messages in thread From: Wermut @ 2015-03-17 18:51 UTC (permalink / raw) To: musl If you like to include these enum names, then they should also be present in the source message. A typical translator, will not now all enum names and the relationship with the msgid. msgid "Permission denied" msgstr "asdf@# lkjk^& (EPERM)" should then be: msgid "Permission denied (EPERM)" msgstr "asdf@# lkjk^& (EPERM)" On Tue, Mar 17, 2015 at 4:38 PM, Rich Felker <dalias@libc.org> wrote: > On Tue, Mar 17, 2015 at 04:02:34PM +0100, Szabolcs Nagy wrote: >> * ???????? <lynx@sibserver.ru> [2015-03-17 13:59:16 +0700]: >> > Attached is my draft of translated strings you mentioned to Russian. >> > Some strings I borrowed from glibc, but only few of them (things like >> > "Broken pipe" and similar). Certain translations may be inaccurate, but >> > mostly if I did not know context I did an additional quick research by >> > grepping man pages. I think this should be additionally reviewed by >> > russian subscribers. >> > >> >> i'm a bit worried about translated error messages, it's always a pain >> to understand bugreports with those >> >> can we include the enum name? >> like >> >> msgid "Permission denied" >> msgstr "asdf@# lkjk^& (EPERM)" > > I'm a bit undecided on this. It's reasonable to ask people reporting > bugs to set their locale temporarily to something the project > maintainers understand (typically English). It's also pretty easy to > grep the .po files or use Google Translate to figure out what the > message says. > > If users with a non-English locale would find those kind of messages > helpful and non-obtrusive (is latin text in the middle of non-latin > obtrusive? perhaps, depending on font?), I'm not opposed to having > them, but I don't think they should be added against the desire of > most users out of an interest in making it easier to interpret bug > reports for us or for other upstreams. > > Rich ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-17 15:38 ` Rich Felker 2015-03-17 18:51 ` Wermut @ 2015-03-18 14:10 ` u-wsnj 2015-03-18 14:26 ` Jens Gustedt 2015-03-19 8:29 ` Justin Cormack 1 sibling, 2 replies; 30+ messages in thread From: u-wsnj @ 2015-03-18 14:10 UTC (permalink / raw) To: musl On Tue, Mar 17, 2015 at 11:38:57AM -0400, Rich Felker wrote: > > msgid "Permission denied" > > msgstr "asdf@# lkjk^& (EPERM)" > > I'm a bit undecided on this. It's reasonable to ask people reporting > bugs to set their locale temporarily to something the project > maintainers understand (typically English). It's also pretty easy to > grep the .po files or use Google Translate to figure out what the > message says. > > If users with a non-English locale would find those kind of messages > helpful and non-obtrusive (is latin text in the middle of non-latin > obtrusive? perhaps, depending on font?), I'm not opposed to having > them, but I don't think they should be added against the desire of > most users out of an interest in making it easier to interpret bug > reports for us or for other upstreams. As an application user I am motivated to be able to report problems as exactly as possible. As a "library user" (either as a packager, application developer, support staff or something else) I find it unfortunate/disturbing to have to "guess" the actual error name, even when a message is in a well known language like English. This is mostly very easy but sometimes less certain, with less usual errors and/or different C libraries which may contain different English strings/spellings too. An error-specific indentifier should IMHO always be present in every message, not translated to a "natural" language with the intention to be translatable back with more or less pain. IOW I'd like to always have the canonical errname in the output, in English too. This would make error messages easier and more robust to interpret. This would also make cut-n-paste web searches for an application problem more reliable, with a better chance to see reports made from different locales and to avoid unrelated natural language. Regards and btw thanks for musl, Rune ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-18 14:10 ` u-wsnj @ 2015-03-18 14:26 ` Jens Gustedt 2015-03-19 8:29 ` Justin Cormack 1 sibling, 0 replies; 30+ messages in thread From: Jens Gustedt @ 2015-03-18 14:26 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 673 bytes --] Am Mittwoch, den 18.03.2015, 15:10 +0100 schrieb u-wsnj@aetey.se: > An error-specific indentifier should IMHO always be present > in every message, not translated to a "natural" language with the > intention to be translatable back with more or less pain. > > IOW I'd like to always have the canonical errname in the output, > in English too. +1 Jens -- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-18 14:10 ` u-wsnj 2015-03-18 14:26 ` Jens Gustedt @ 2015-03-19 8:29 ` Justin Cormack 2015-03-19 8:55 ` Jens Gustedt 2015-03-19 12:41 ` u-wsnj 1 sibling, 2 replies; 30+ messages in thread From: Justin Cormack @ 2015-03-19 8:29 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 1891 bytes --] On Mar 18, 2015 11:10 PM, <u-wsnj@aetey.se> wrote: > > On Tue, Mar 17, 2015 at 11:38:57AM -0400, Rich Felker wrote: > > > msgid "Permission denied" > > > msgstr "asdf@# lkjk^& (EPERM)" > > > > I'm a bit undecided on this. It's reasonable to ask people reporting > > bugs to set their locale temporarily to something the project > > maintainers understand (typically English). It's also pretty easy to > > grep the .po files or use Google Translate to figure out what the > > message says. > > > > If users with a non-English locale would find those kind of messages > > helpful and non-obtrusive (is latin text in the middle of non-latin > > obtrusive? perhaps, depending on font?), I'm not opposed to having > > them, but I don't think they should be added against the desire of > > most users out of an interest in making it easier to interpret bug > > reports for us or for other upstreams. > > As an application user I am motivated to be able to report problems as > exactly as possible. > > As a "library user" (either as a packager, application developer, > support staff or something else) I find it unfortunate/disturbing to > have to "guess" the actual error name, even when a message is in a well > known language like English. > > This is mostly very easy but sometimes less certain, with less usual > errors and/or different C libraries which may contain different English > strings/spellings too. > > An error-specific indentifier should IMHO always be present > in every message, not translated to a "natural" language with the > intention to be translatable back with more or less pain. > > IOW I'd like to always have the canonical errname in the output, > in English too. > > This would make error messages easier and more robust to interpret. > Would it make sense for the canonical names to be the output in the C locale and English if you set an English locale? Justin [-- Attachment #2: Type: text/html, Size: 2390 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-19 8:29 ` Justin Cormack @ 2015-03-19 8:55 ` Jens Gustedt 2015-03-19 12:41 ` u-wsnj 1 sibling, 0 replies; 30+ messages in thread From: Jens Gustedt @ 2015-03-19 8:55 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 693 bytes --] Am Donnerstag, den 19.03.2015, 08:29 +0000 schrieb Justin Cormack: > Would it make sense for the canonical names to be the output in the C > locale and English if you set an English locale? I don't think so. People with English locale typically to even switch to the native locale, I guess, so a lot of code would change behavior for a lot of users with that approach. Jens -- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-19 8:29 ` Justin Cormack 2015-03-19 8:55 ` Jens Gustedt @ 2015-03-19 12:41 ` u-wsnj 2015-03-19 17:25 ` stephen Turner 2015-03-19 17:54 ` Rich Felker 1 sibling, 2 replies; 30+ messages in thread From: u-wsnj @ 2015-03-19 12:41 UTC (permalink / raw) To: musl On Thu, Mar 19, 2015 at 08:29:41AM +0000, Justin Cormack wrote: > On Mar 18, 2015 11:10 PM, <u-wsnj@aetey.se> wrote: > > IOW I'd like to always have the canonical errname in the output, > > in English too. > Would it make sense for the canonical names to be the output in the C > locale and English if you set an English locale? What I am after is seeing "EXXXXX" as a part of the message with any LANG, including English: LANG=en: "No such file or directory (ENOENT)" LANG=xx: "&((/&=(/%&/(&%/(/)(/&/ ENOENT" ... It could be nice to have a common convention for all languages about the formatting of the error reference, like parentheses around the name and/or placing it rightmost, but this is probably impossible with some languages. Rune ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-19 12:41 ` u-wsnj @ 2015-03-19 17:25 ` stephen Turner 2015-03-20 1:58 ` Weldon Goree 2015-03-19 17:54 ` Rich Felker 1 sibling, 1 reply; 30+ messages in thread From: stephen Turner @ 2015-03-19 17:25 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 525 bytes --] > > > It could be nice to have a common convention for all languages > about the formatting of the error reference, like parentheses > around the name and/or placing it rightmost, but this is probably > impossible with some languages. > > Rune > > with stuff like google translate the only issue i see is the grammatical differences in languages. That could be bypassed with the use of a numerical or hex tag but like rich said, I dont really see what improvement that would make much beyond the grammatical. thanks stephen [-- Attachment #2: Type: text/html, Size: 798 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-19 17:25 ` stephen Turner @ 2015-03-20 1:58 ` Weldon Goree 2015-03-20 3:11 ` Rich Felker 0 siblings, 1 reply; 30+ messages in thread From: Weldon Goree @ 2015-03-20 1:58 UTC (permalink / raw) To: musl On Thu, Mar 19, 2015 at 01:25:19PM -0400, stephen Turner wrote: > with stuff like google translate the only issue i see is the grammatical > differences in languages. That could be bypassed with the use of a > numerical or hex tag but like rich said, I dont really see what improvement > that would make much beyond the grammatical. Are these messages ever created (and localized) on the fly (beyond the insertion of, say, run-specific memory addresses, file names, etc.)? Weldon ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-20 1:58 ` Weldon Goree @ 2015-03-20 3:11 ` Rich Felker 0 siblings, 0 replies; 30+ messages in thread From: Rich Felker @ 2015-03-20 3:11 UTC (permalink / raw) To: Weldon Goree; +Cc: musl On Fri, Mar 20, 2015 at 07:28:32AM +0530, Weldon Goree wrote: > On Thu, Mar 19, 2015 at 01:25:19PM -0400, stephen Turner wrote: > > with stuff like google translate the only issue i see is the grammatical > > differences in languages. That could be bypassed with the use of a > > numerical or hex tag but like rich said, I dont really see what improvement > > that would make much beyond the grammatical. > > Are these messages ever created (and localized) on the fly (beyond the > insertion of, say, run-specific memory addresses, file names, etc.)? No; they are a pure function of a single small integer. Rich ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-19 12:41 ` u-wsnj 2015-03-19 17:25 ` stephen Turner @ 2015-03-19 17:54 ` Rich Felker 2015-03-20 9:20 ` u-wsnj 1 sibling, 1 reply; 30+ messages in thread From: Rich Felker @ 2015-03-19 17:54 UTC (permalink / raw) To: musl On Thu, Mar 19, 2015 at 01:41:05PM +0100, u-wsnj@aetey.se wrote: > On Thu, Mar 19, 2015 at 08:29:41AM +0000, Justin Cormack wrote: > > On Mar 18, 2015 11:10 PM, <u-wsnj@aetey.se> wrote: > > > IOW I'd like to always have the canonical errname in the output, > > > in English too. > > > Would it make sense for the canonical names to be the output in the C > > locale and English if you set an English locale? > > What I am after is seeing "EXXXXX" as a part of the message with any LANG, > including English: > > LANG=en: "No such file or directory (ENOENT)" > LANG=xx: "&((/&=(/%&/(&%/(/)(/&/ ENOENT" > ... > > It could be nice to have a common convention for all languages > about the formatting of the error reference, like parentheses > around the name and/or placing it rightmost, but this is probably > impossible with some languages. The issues I'm somewhat concerned with are: - Does this interfere with proper flow of RTL text? In absence of bidi nesting chars, I would think the answer might be yes. - Does it result in ugly mix of unmatching fonts in UI, possibly even alterring line spacing? Keep in mind that error messages are not necessarily bugs to be reported upstream but may be informative to users directly. For example a GUI app could be reporting to the user that they file they tried to open is not accessible. Rich ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-19 17:54 ` Rich Felker @ 2015-03-20 9:20 ` u-wsnj 2015-03-20 20:27 ` Rich Felker 0 siblings, 1 reply; 30+ messages in thread From: u-wsnj @ 2015-03-20 9:20 UTC (permalink / raw) To: musl On Thu, Mar 19, 2015 at 01:54:43PM -0400, Rich Felker wrote: > > What I am after is seeing "EXXXXX" as a part of the message with any LANG, > > including English: > > > > LANG=en: "No such file or directory (ENOENT)" > > LANG=xx: "&((/&=(/%&/(&%/(/)(/&/ ENOENT" > > ... > The issues I'm somewhat concerned with are: > > - Does this interfere with proper flow of RTL text? In absence of bidi > nesting chars, I would think the answer might be yes. Regrettably I think it would. Then, I'd be fine with TNEONE :) > - Does it result in ugly mix of unmatching fonts in UI, possibly even > alterring line spacing? Sometimes quite certainly, but I see this as an implementation issue of the rendering systems, the inability to mix strings of different "kinds of glyphs" is artificial. > Keep in mind that error messages are not necessarily bugs to be > reported upstream but may be informative to users directly. For > example a GUI app could be reporting to the user that they file they > tried to open is not accessible. I want this even as an application user, without any bug reports involved. When an error code passes several layers before being shown to the user it can "fall out of context" and become misleading. I encountered ENOENT in a file related operation which indicated that a different object than a "file or directory" was missing. It would take less time to realize what happened have I thought about "which errcode it was" as I finally did, not "why is the file missing". In other words, I object to the need to mentally "translate back" before trusting what the message literally says. In the same way as virtually no one uses "internationalized/localized" keywords in a programming language (certain spreadsheets come to my mind as a terrible example of the opposite :) I'd like short and universal identifiers for the errors, besides those messages oriented towards humans with unspecified technical proficiency. This would somewhat impact all users (one extra word per error message) but would improve the life of some of the users and of many developers. May be I wish too much :) Rune ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-20 9:20 ` u-wsnj @ 2015-03-20 20:27 ` Rich Felker 0 siblings, 0 replies; 30+ messages in thread From: Rich Felker @ 2015-03-20 20:27 UTC (permalink / raw) To: musl On Fri, Mar 20, 2015 at 10:20:52AM +0100, u-wsnj@aetey.se wrote: > On Thu, Mar 19, 2015 at 01:54:43PM -0400, Rich Felker wrote: > > > What I am after is seeing "EXXXXX" as a part of the message with any LANG, > > > including English: > > > > > > LANG=en: "No such file or directory (ENOENT)" > > > LANG=xx: "&((/&=(/%&/(&%/(/)(/&/ ENOENT" > > > ... > > > The issues I'm somewhat concerned with are: > > > > - Does this interfere with proper flow of RTL text? In absence of bidi > > nesting chars, I would think the answer might be yes. > > Regrettably I think it would. Then, I'd be fine with TNEONE :) TNEONE is not what would happen. Rather, if you had a RTL sequence containing an error message, the parts before and after the latin E* text could get their positions swapped, I think. This could be solved by using LTR embedding chars around the E* code, but I'm doubtful that this would be well-supported on terminals. Note that I'm not an expert on bidi text so I might have this wrong, but I know enough to know it's a concern that it might get messed up. > > - Does it result in ugly mix of unmatching fonts in UI, possibly even > > alterring line spacing? > > Sometimes quite certainly, but I see this as an implementation issue > of the rendering systems, the inability to mix strings of different > "kinds of glyphs" is artificial. Tell me when you finish a set of fonts with uniform style and spacing for all the world's scripts. :-) Rich ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-17 15:02 ` Szabolcs Nagy 2015-03-17 15:38 ` Rich Felker @ 2015-03-18 7:15 ` Рысь 1 sibling, 0 replies; 30+ messages in thread From: Рысь @ 2015-03-18 7:15 UTC (permalink / raw) To: musl On Tue, 17 Mar 2015 16:02:34 +0100 Szabolcs Nagy <nsz@port70.net> wrote: > * ???????? <lynx@sibserver.ru> [2015-03-17 13:59:16 +0700]: > > Attached is my draft of translated strings you mentioned to Russian. > > Some strings I borrowed from glibc, but only few of them (things > > like "Broken pipe" and similar). Certain translations may be > > inaccurate, but mostly if I did not know context I did an > > additional quick research by grepping man pages. I think this > > should be additionally reviewed by russian subscribers. > > > > i'm a bit worried about translated error messages, it's always a pain > to understand bugreports with those > > can we include the enum name? > like > > msgid "Permission denied" > msgstr "asdf@# lkjk^& (EPERM)" Why? Should there be enforcement like "To report bugs, please do: ... * Set LC_ALL=C environment variable to leave any translated error strings back in English " I always did that for years. And, if I remember, Rich wanted(?) to have a special locale where all error strings are replaced with enum names, so programs will start to print "program: /dev/full: ENOSPC". This is unrelated, just a reminder :) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-17 6:59 ` Рысь 2015-03-17 15:02 ` Szabolcs Nagy @ 2015-03-24 3:59 ` Рысь 1 sibling, 0 replies; 30+ messages in thread From: Рысь @ 2015-03-24 3:59 UTC (permalink / raw) To: musl On Tue, 17 Mar 2015 13:59:16 +0700 Рысь <lynx@sibserver.ru> wrote: > > Attached is my draft of translated strings you mentioned to Russian. > Some strings I borrowed from glibc, but only few of them (things like > "Broken pipe" and similar). Certain translations may be inaccurate, > but mostly if I did not know context I did an additional quick > research by grepping man pages. I think this should be additionally > reviewed by russian subscribers. > > File compiles with msgfmt but I did not tested it. I will do when I > will establish a locale kvm machine to test and finally fix my locale > issue. > > Let me know if additional places in libc need to be translated. I did something wrong probably because attached draft does not work in any way. It's compiled version is mmaped but no translation is done. Even date +%x shows original "%m/%d/%y" format. However test file I tried previously does work. What's wrong with it? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: libintl: stubs or working functions? 2015-03-15 23:54 ` Rich Felker 2015-03-16 4:18 ` Рысь @ 2015-03-16 9:27 ` Szabolcs Nagy 1 sibling, 0 replies; 30+ messages in thread From: Szabolcs Nagy @ 2015-03-16 9:27 UTC (permalink / raw) To: musl * Rich Felker <dalias@libc.org> [2015-03-15 19:54:18 -0400]: > you should set). Then LC_DATE=ru_RU would give your desired > formatting. > s/LC_DATE/LC_TIME/ ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2015-03-24 3:59 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-03-05 9:36 libintl: stubs or working functions? Рысь 2015-03-06 22:24 ` Rich Felker 2015-03-08 9:22 ` Рысь 2015-03-09 0:56 ` Rich Felker 2015-03-15 12:33 ` Рысь 2015-03-15 23:54 ` Rich Felker 2015-03-16 4:18 ` Рысь 2015-03-16 13:04 ` Szabolcs Nagy 2015-03-16 13:35 ` Szabolcs Nagy 2015-03-16 13:41 ` Szabolcs Nagy 2015-03-17 1:40 ` Рысь 2015-03-17 2:01 ` Rich Felker 2015-03-17 6:59 ` Рысь 2015-03-17 15:02 ` Szabolcs Nagy 2015-03-17 15:38 ` Rich Felker 2015-03-17 18:51 ` Wermut 2015-03-18 14:10 ` u-wsnj 2015-03-18 14:26 ` Jens Gustedt 2015-03-19 8:29 ` Justin Cormack 2015-03-19 8:55 ` Jens Gustedt 2015-03-19 12:41 ` u-wsnj 2015-03-19 17:25 ` stephen Turner 2015-03-20 1:58 ` Weldon Goree 2015-03-20 3:11 ` Rich Felker 2015-03-19 17:54 ` Rich Felker 2015-03-20 9:20 ` u-wsnj 2015-03-20 20:27 ` Rich Felker 2015-03-18 7:15 ` Рысь 2015-03-24 3:59 ` Рысь 2015-03-16 9:27 ` Szabolcs Nagy
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).