[Bug localedata/18408] Provide software utility to permit user created custom locales

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18408

--- Comment #12 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to James B. Byrne from comment #9)
> (In reply to Marko Myllynen from comment #5)
> > The upstream localedef(1) manual page was contributed less than a year ago
> > while RHEL 6 was released in 2010 so it's no wonder it's not part of RHEL 6.
> > The used date and time formats are described in strftime(3).
> > 
> > I don't think a special locale editing tool is part of the scope for glibc
> > as the locale definition files can already be edited with standard
> > utilities, perhaps such a special tool could be something for projects like
> > GNOME or KDE to consider.
> 
> So all anyone need do to create a custom locale file is to:
> 
> 1. discover the library builder utility 'localedef'
> 2. discover and copy an existing file from the locales shipped with the
> distro
> 3. figure out what this sort of stuff means:
> date_fmt	"<U0025><U0061><U0020><U0025><U0062><U0020><U0025><U0065>/
> <U0020><U0025><U0048><U003A><U0025><U004D><U003A><U0025><U0053><U0020>/
> <U0025><U005A><U0020><U0025><U0059>"
> 4. infer that this somehow is related to strftime
> 5. determine the exact strftime format field desired
> 6. translate string into utf-8 code points
> 7. manually edit the locale copy file with vi, nano, emac or equivalent and
> insert the the updated utf-8 code points
> 8. discover through trial and error how the localedef utility must be used
> to  build the custom library files from the edited custom locale definition
> files
> 9. configure the system to use the new locale files
> 
> What could be simpler?  After all, it did not take me much more than four or
> five days to figure this all out on my own. I have probably forgotten a
> number of other steps that were also necessary and so are not listed here. 
> And I was not the first to run into this morass.  I discovered my experience
> was shared by the author of Bug #985981 only later. No doubt there are many
> others who either give up or lack the confidence or energy to file a bug
> report.

I hope you're joking right? That's way too many steps. As a senior project
developer I admit it's way too hard to create locale customizations. However, a
tool to do so might be better created outside of glibc and as a frontend to
localedef.

> What I am reading here is that despite being the source of the LOCALE
> definitions the maintainers do not think it within scope to provide a
> utility to actually create one.  Am I correct?  

No, you could argue for a CLI tool that lives with glibc and shares code to be
used to (a) spit out a template from an existing locale definition (b) let you
edit it (c) install it as a file or into locale-archive (system-wide or user).

> And yet some of the maintainers also express the opinion that the locale
> files provided do not need to meet the national regulatory requirements of
> places for which they do provide locales.  See bug: Bug 12731 (four years
> old) and Bug 9842 (six years old).  This might get addressed now, see: Bug
> 16668 ( over a year old).  

Yes, that is true. It's hard to validate this data and there are few interested
developers working on it. We went through a large spat of cleanups a few years
back where I diligently emailed 20 or 30 embassys and none got back to me. My
inclination is that legal requirements are moot at this point, users want
locales that match their customs and styles, and governments need custom
locales anyeways to meet their often stricter need.

> But it is now 16 years since the legal requirement referred to in this
> reports went into effect in Canada. It seems to me an immoderate amount of
> delay in addressing a rather simple issue.  I would suggest that this is
> fairly substantial evidence that something needs to be provided to manage
> locale definitions that is far more accessible to the average system
> administrator than the existing arcana.

I agree.

-- 
You are receiving this mail because:
You are on the CC list for the bug.