Re: libintl: stubs or working functions?

[Rich Felker <dalias@libc.org>]

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