they use 24-hour clock notation. The visible change is that w(1) now
uses 24-hour clock format as it checks for t_fmt_ampm presence.
PR: 231771
Submitted by: Christoph Schönweiler <public2016@hauptsignal.at>
Reviewed by: bapt
Approved by: kib (mentor, implicit)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D17945
in Italy, and is not related to Canada.
While here, remove the header as we do NOT currently use CLDR data to
generate timedef, and it's misleading.
PR: 225855
Reviewed by: bapt
Approved by: re (gjb), kib (mentor)
Differential Revision: https://reviews.freebsd.org/D17551
for Chinese locales.
As mentioned in the commit message of r289041, nl_langinfo(ABMON_*) only
returned numbers when using a Chinese locale, this causes problems in
applications that put the short month name and the day of the month together.
Spotted by: Ting-Wei Lan <lantw44 gmail com>
While CLDR brings us a good and up to date source data to generate locales for
all databses we are using for locales, it is not the case of LC_TIME. Where it
does not defines the informations we need.
Put back all the date and time formats from the old locales.
Make it statically for now (in order to be able to merge it now into
11.0-RELEASE). The generation tools will be updated soon.
That gives us time to properly work on LC_TIME during the 12 timeframe.
While here fix abbreviated month for af_ZA (which are already fixed in CLDR
data upstream)
In locales where AP/PM was not defined before CLDR data, remove again the AP/PM
informations
For locales where AP/PM was defined before CLDR data, keep the CLDR information
which was properly translated.
MFC after: 3 days
For all locales with variants:
- if no ambiguity on the locale (only one variant) just use the regular name
- if ambiguity, pick one as default and append @<variant> to the others
respecting POSIX
As a result:
- All the 3 components locales added recently are renamed to the usual 2
components version for all but sr_RS.UTF-8
- Set sr_RS.UTF-8 to the cyrillic variant
- Add sr_RS.UTF-8@latin
- Remove the symlinks aliases they were created to represent the 2 components
version as aliasas and are now useless
- Update the OptionalObsoleteFiles.inc and ObsoleteFiles.inc to reflect those
changes
Discussed with: ache@
Approved by: re@ (gjb)
Serbian locales have triple components to represent the 2 variations of the
locale: Latin and Cyrillic. Previously the tools generatic the locale were
appending both definitions instead of differentiating them.
Reported by: ache
Approved by: re (gjb)
For Russian:
- Convert AM/PM which are badly formatted in CLDR to replace it by the proper
cyrillic
- Add a dependency on Text::Iconv so non unicode get the proper encoding for
AM/PM
- fix the date format having 'r.,' and convert it to 'r.' (also fixed in Bulgarian)
For All:
- Use complete Day of Week instead of the abbreviated one
Reported by: ache
directory symlink when the target directory does not exist. This will
cause an error instead of a broken setup.
Sponsored by: EMC / Isilon Storage Division
Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
we were not able to change c_fmt without breaking these utilities. Since
ache fixed all known issues 8 years ago, now we make ko_KR more usable.
Better late than never...
Catalan language is not only spoken in Spain (ca_ES), but also
in Andorra, France and Italy. In Andorra it is the official
language.
(see http://en.wikipedia.org/wiki/Catalan_language#Geographic_distribution)
Add a bunch of symlinks to between ca_ES and ca_AD, ca_FR and ca_IT.
PR: conf/92541
Submitted by: <rmh@io.debian.net>
MFC after: 1 week
From the submitter:
DIN 5008 (German norm for text processing) defines the old date
format (%d.%m.%Y) to be obsolete and to be used only, if unambigous.
In international communications the new format (%Y-%m-%d) is now
required and FreeBSD should respect this.
References:
- DIN 5008
- EN 28 601
- ISO 8601
Thanks to Oliver Lietz for bringing this to my attention.
PR: conf/72076
Submitted by: Peter Wullinger <some-mail-drop@gmx.net>
MFC after: 1 week