From: Vicente BOTET <vicente.botet@wanadoo.fr>
If "File was opened {1} day ago" is not in dictionary that it would be used as no Hebrew alternative provided, also it would have 2 plural forms (as English) instead of 3 (in Hebrew).
I insists, could you show the catalog associated to this translation in English and in Hebrew? I'm sure I'm missing something and I don't reach to see what.
The hebrew catalog looks like he.po # translation of foo.po to Hebrew "Project-Id-Version: foo\n" "PO-Revision-Date: 2008-06-07 15:04+0300\n" "Last-Translator: Artyom <artyomtnk@yahoo.com>\n" "Language-Team: Hebrew <en@li.org>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=3; plural= n==1 ? 0 : (n == 2 ? 1 : 2);\n" "X-Generator: KBabel 1.11.4\n" msgid "File was opened {1} day ago" msgid_plural "File was opened {1} days ago" msgstr[0] "Kovetz niftah lifney yom {1}" msgstr[1] "Kovetz niftah lifney yomaim" msgstr[2] "Kovetz niftah lifney {2} yamim" The English is the original string. In Japanese or Chinese (with one form) it would be ja.po ... "Plural-Forms: nplurals=1; plural=0;\n" ... msgid "File was opened {1} day ago" msgid_plural "File was opened {1} days ago" msgstr[0] "Some Japanese text {1} some Japanese text" ... The "Plural-Forms:" section of meta record describes the format of plural forms: their number and equation in C that calculates it from parameter, the facet that loads catalog parses the C equation and know how to calculate it.
format(translate("Format date with H-M-S","{1}, {2}, {3}")) % format(translate("Format date with H-M-S","{1} hour","{1} hours")) % format(translate("Format date with H-M-S","{1} minute","{1} minutes")) % format(translate("Format date with H-M-S","{1} second","{1} seconds"))
The single problem I see which character use to split the string. Maybe % could be used
translate("%1 hours%,% %2 minutes%,% %3 seconds") % h % m % s
Not sure about it how exactly you want to do this? Would format(translate("Format date with H-M-S", "[{1} hour|{1} hours], [{2} minute|{2} minutes], [{3} second|{3} seconds]", h,m,s)) %h % m % s Is better? I don't know... Need to think about, because there may be more corner cases that I don't see yet.
The C++0x had deprecated std::auto_ptr that everybody uses and had given std::unique_ptr.
You are suggesting to enforce bad design to good facet just because it exists and nobody uses it?
I disagree. This std::messages facet should be deprecated or even removed.
No. I'm just telling that if you have valid arguments it will be better to deprecate one and add one that is better. But having two catalogs is not good.
Yes I recommend to deprecate.
For example if I want to make Chrrno internationalizable I can just use Std facet message until there is a better facet.
And it would work only on... Linux - gcc supports locales only on Linux - MSVC does not support messages at all. That is the sad reality.
In order to make useful TR2 proposal you should do some groundbreaking and do things like:
1. Standardize locale names 2. Standardize messages catalogs formats 3. Rewrite some of existing facets completely 4. Deprecate some of the facets and functions.
The 3 and 4 are quite easy to do however the 1st and the 2nd would be very hard if possible at all.
So, are you saying that we can not have a other than implementation defined standard for localization?
I'm just telling it would not be simple at all, especially that some ground breaking things like using UTF-8 by default, using specific messages catalog and so on. Without it locales would remain useless as they today.
Well, having better facets could be one step ahead.
But it would not be enough. See, if the state of the implementation (not interface) of the current facets was good it would be very-very-very useful part of C++ even in its limited way... But it isn't.
This what really concerns me in the standardization of localization facilities.
I really suggest you to participate on the standardization of a better locale library proposal, at the end this is also one of the goals of Boost.
Yes I understand and see and I think it may have a chance. Artyom