libintl: stubs or working functions?

libintl: stubs or working functions?

[Рысь]

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.

Re: libintl: stubs or working functions?

[Rich Felker]

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

Re: libintl: stubs or working functions?

[Рысь]

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.

Re: libintl: stubs or working functions?

[Rich Felker]

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

Re: libintl: stubs or working functions?

[Рысь]

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.

Re: libintl: stubs or working functions?

[Rich Felker]

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

Re: libintl: stubs or working functions?

[Рысь]

[-- 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)                           = ?

Re: libintl: stubs or working functions?

[Szabolcs Nagy]

* ???????? <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..

Re: libintl: stubs or working functions?

[Szabolcs Nagy]

* 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.

Re: libintl: stubs or working functions?

[Szabolcs Nagy]

* ???????? <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, "")

Re: libintl: stubs or working functions?

[Рысь]

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?

Re: libintl: stubs or working functions?

[Rich Felker]

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

Re: libintl: stubs or working functions?

[Рысь]

[-- 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 "Неправильный системный вызов"

Re: libintl: stubs or working functions?

[Szabolcs Nagy]

* ???????? <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)"

Re: libintl: stubs or working functions?

[Rich Felker]

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

Re: libintl: stubs or working functions?

[Wermut]

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

Re: libintl: stubs or working functions?

[u-wsnj]

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

Re: libintl: stubs or working functions?

[Jens Gustedt]

[-- 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 --]

Re: libintl: stubs or working functions?

[Justin Cormack]

[-- 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 --]

Re: libintl: stubs or working functions?

[Jens Gustedt]

[-- 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 --]

Re: libintl: stubs or working functions?

[u-wsnj]

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

Re: libintl: stubs or working functions?

[stephen Turner]

[-- 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 --]

Re: libintl: stubs or working functions?

[Weldon Goree]

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 

Re: libintl: stubs or working functions?

[Rich Felker]

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

Re: libintl: stubs or working functions?

[Rich Felker]

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

Re: libintl: stubs or working functions?

[u-wsnj]

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

Re: libintl: stubs or working functions?

[Rich Felker]

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

Re: libintl: stubs or working functions?

[Рысь]

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 :)

Re: libintl: stubs or working functions?

[Рысь]

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?

Re: libintl: stubs or working functions?

[Szabolcs Nagy]

* 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/