[locale] Review. Internationalization library?
Hi, from the name of the library Boost.Locale and the section "What is Boost.Locale?" I didn't get enough information about the motivation and the scope of the library. I think that maybe be this is due to the fact that the dependency to ICU hides a lot of features the library provides. I think that a direct link to what ICU is is a must, but I would expect a little bit more than "On the other hand, there is a great, well debugged, high quality, widely used ICU library that gives all of the goodies" in this section.
From my side if the library was named Boost.Internationalization I'm sure I would had take a look long time ago. Do you think that this renaming (or a shorter one) will cover the whole library or there are parts of the library that don't fall in the internationalization domain?
As the review period has been extended, I will try to review at least the documentation. Best, Vicente
Message du 16/04/11 08:04 De : "Vicente BOTET" A : boost@lists.boost.org Copie à : Objet : [boost] [locale] Review. Internationalization library?
Hi,
from the name of the library Boost.Locale and the section "What is Boost.Locale?" I didn't get enough information about the motivation and the scope of the library. I think that maybe be this is due to the fact that the dependency to ICU hides a lot of features the library provides. I think that a direct link to what ICU is is a must, but I would expect a little bit more than "On the other hand, there is a great, well debugged, high quality, widely used ICU library that gives all of the goodies" in this section.
From my side if the library was named Boost.Internationalization I'm sure I would had take a look long time ago. Do you think that this renaming (or a shorter one) will cover the whole library or there are parts of the library that don't fall in the internationalization domain?
As the review period has been extended, I will try to review at least the documentation.
I have made a diagonal reading and I find your library really interesting. I think I will spent quite more time reviewing it. I have just a first minimal and formal remark. When I see the overloading of the translate function message boost::locale::translate (char const *msg) message boost::locale::translate (char const *context, char const *msg) message boost::locale::translate (char const *single, char const *plural, int n) message boost::locale::translate (char const *context, char const *single, char const *plural, int n) message boost::locale::translate (std::string const &msg) message boost::locale::translate (std::string const &context, std::string const &msg) message boost::locale::translate (std::string const &context, std::string const &single, std::string const &plural, int n) message boost::locale::translate (std::string const &single, std::string const &plural, int n) this let me think that it would be difficult to know know what is the message, the context, the domain, whether the message is the singular or plural form. The equivalent for (w)gettext uses the c-like idiom, i.e. uses different names. std::string boost::locale::gettext (char const *id, std::locale const &loc=std::locale()) std::string boost::locale::ngettext (char const *s, char const *p, int n, std::locale const &loc=std::locale()) std::string boost::locale::dgettext (char const *domain, char const *id, std::locale const &loc=std::locale()) std::string boost::locale::dngettext (char const *domain, char const *s, char const *p, int n, std::locale const &loc=std::locale()) std::string boost::locale::pgettext (char const *context, char const *id, std::locale const &loc=std::locale()) std::string boost::locale::npgettext (char const *context, char const *s, char const *p, int n, std::locale const &loc=std::locale()) std::string boost::locale::dpgettext (char const *domain, char const *context, char const *id, std::locale const &loc=std::locale()) std::string boost::locale::dnpgettext (char const *domain, char const *context, char const *s, char const *p, int n, std::locale const &loc=std::locale()) Neither is satisfying me. I was wondering if the use of Boost.Parameters could help. An alternative could also be to define some thin wrappers that state clearly what is the meaning of the string or const char * parameters, for example we could have struct domain { domain(const char*); domain(std::string const&); operator const char*() const; operator std::string() const; }; The same for context, plural. Note that we don't need to wrap the message itself as this parameter is mandatory. The examples cout << format(translate("You have 1 file in the directory", "You have {1} files in the directory",files)) % files << endl; button->setLabel(translate("File","open")); could be written as cout << format(translate("You have 1 file in the directory", plural("You have {1} files in the directory"),files)) % files << endl; button->setLabel(translate(context("File"),"open")); With this modification, the (w)gettext could all share the same names and there will be no need to use c-like names. What you think? Best, Vicente
I have made a diagonal reading and I find your library really interesting. I think I will spent quite more time reviewing it.
I have just a first minimal and formal remark. When I see the overloading of the translate function
message boost::locale::translate (char const *msg) message boost::locale::translate (char const *context, char const *msg) message boost::locale::translate (char const *single, char const *plural, int n) message boost::locale::translate (char const *context, char const *single, char const *plural, int n) message boost::locale::translate (std::string const &msg) message boost::locale::translate (std::string const &context, std::string const &msg) message boost::locale::translate (std::string const &context, std::string const &single, std::string const &plural, int n) message boost::locale::translate (std::string const &single, std::string const &plural, int n)
this let me think that it would be difficult to know know what is the
message,
the context, the domain, whether the message is the singular or plural form.
This is the general concept of how gettext used around. So I stick with its conversion extending it, same concept used in Qt. It is quite common. I agree that it is not perfect but it seems to be ok.
The equivalent for (w)gettext uses the c-like idiom, i.e. uses different names.
std::string boost::locale::gettext (char const *id, std::locale const &loc=std::locale()) std::string boost::locale::ngettext (char const *s, char const *p, int n, std::locale const &loc=std::locale()) std::string boost::locale::dgettext (char const *domain, char const *id, std::locale const &loc=std::locale()) std::string boost::locale::dngettext (char const *domain, char const *s, char const *p, int n, std::locale const &loc=std::locale()) std::string boost::locale::pgettext (char const *context, char const *id, std::locale const &loc=std::locale()) std::string boost::locale::npgettext (char const *context, char const *s, char const *p, int n, std::locale const &loc=std::locale()) std::string boost::locale::dpgettext (char const *domain, char const *context, char const *id, std::locale const &loc=std::locale()) std::string boost::locale::dnpgettext (char const *domain, char const *context, char const *s, char const *p, int n, std::locale const &loc=std::locale())
Neither is satisfying me.
These are mostly gettext compatibility functions so users familiar with gettext would find themselves with (almost) same API.
I was wondering if the use of Boost.Parameters could help.
I'm not really familiar with Boost.Parameters but from quick glance it requires not-so trivial template metaprogramming but what is even more important I'm afraid that things like translate(context_ = "File","Open") May scary off some average C++ programmers that would not understand what is this thing context_ = "File" Finally I want Boost.Locale be used by not brilliant C++ programmers as well. I know what hard times I have explaining about boost::bind to average C++ programmers so making things like that would not help too much.
An alternative could also be to define some thin wrappers that state clearly what is the meaning of the string or const char * parameters, for example we could have
struct domain { domain(const char*); domain(std::string const&); operator const char*() const; operator std::string() const; };
The same for context, plural. Note that we don't need to wrap the message itself as this parameter is mandatory.
The examples
cout << format(translate("You have 1 file in the directory", "You have {1} files in the directory",files)) % files << endl;
button->setLabel(translate("File","open"));
could be written as
cout << format(translate("You have 1 file in the directory", plural("You have {1} files in the directory"),files)) % files << endl;
button->setLabel(translate(context("File"),"open"));
With this modification, the (w)gettext could all share the same names and there will be no need to use c-like names.
What you think?
This one more interesting. However there an important point to check: Integration with xgettext - would it be able to read this or entire new xgettext should be developed to extract strings. I need to think about, probably it may be an alternative.
Best, Vicente
Thanks, Artyom
Message du 16/04/11 15:01 De : "Artyom" A : boost@lists.boost.org Copie à : Objet : Re: [boost] [locale] Review. Internationalization library?
I have made a diagonal reading and I find your library really interesting. I think I will spent quite more time reviewing it.
I have just a first minimal and formal remark. When I see the overloading of the translate function
message boost::locale::translate (char const *msg) message boost::locale::translate (char const *context, char const *msg) message boost::locale::translate (char const *single, char const *plural, int n) message boost::locale::translate (char const *context, char const *single, char const *plural, int n) message boost::locale::translate (std::string const &msg) message boost::locale::translate (std::string const &context, std::string const &msg) message boost::locale::translate (std::string const &context, std::string const &single, std::string const &plural, int n) message boost::locale::translate (std::string const &single, std::string const &plural, int n)
this let me think that it would be difficult to know know what is the
message,
the context, the domain, whether the message is the singular or plural form.
This is the general concept of how gettext used around. So I stick with its conversion extending it, same concept used in Qt. It is quite common.
I agree that it is not perfect but it seems to be ok.
I'm sure that you will reach to provide something clearer that don't adhere to gettext (which is hidden for the user).
The equivalent for (w)gettext uses the c-like idiom, i.e. uses different names.
std::string boost::locale::gettext (char const *id, std::locale const &loc=std::locale()) std::string boost::locale::ngettext (char const *s, char const *p, int n, std::locale const &loc=std::locale()) std::string boost::locale::dgettext (char const *domain, char const *id, std::locale const &loc=std::locale()) std::string boost::locale::dngettext (char const *domain, char const *s, char const *p, int n, std::locale const &loc=std::locale()) std::string boost::locale::pgettext (char const *context, char const *id, std::locale const &loc=std::locale()) std::string boost::locale::npgettext (char const *context, char const *s, char const *p, int n, std::locale const &loc=std::locale()) std::string boost::locale::dpgettext (char const *domain, char const *context, char const *id, std::locale const &loc=std::locale()) std::string boost::locale::dnpgettext (char const *domain, char const *context, char const *s, char const *p, int n, std::locale const &loc=std::locale())
Neither is satisfying me.
These are mostly gettext compatibility functions so users familiar with gettext would find themselves with (almost) same API.
You are not forced to provide C-like interfaces in a Boost library to content some users that know the gettext interface. It is quite ugly.
I was wondering if the use of Boost.Parameters could help.
I'm not really familiar with Boost.Parameters but from quick glance it requires not-so trivial template metaprogramming but what is even more important I'm afraid that things like
translate(context_ = "File","Open")
I had no issue explaining this idiom to users of a library. Another question is for the implementer of the library, some more explanation will be needed.
May scary off some average C++ programmers that would not understand what is this thing
context_ = "File"
Finally I want Boost.Locale be used by not brilliant C++ programmers as well.
I know what hard times I have explaining about boost::bind to average C++ programmers so making things like that would not help too much.
Well, it is your library. It is up to you to maintain ugly interfaces like the preceding ones.
From my side the add a -1 to the review. Fortunately there are a lot of positive parts.
An alternative could also be to define some thin wrappers that state clearly what is the meaning of the string or const char * parameters, for example we could have
struct domain { domain(const char*); domain(std::string const&); operator const char*() const; operator std::string() const; };
The same for context, plural. Note that we don't need to wrap the message itself as this parameter is mandatory.
The examples
cout << format(translate("You have 1 file in the directory", "You have {1} files in the directory",files)) % files << endl;
button->setLabel(translate("File","open"));
could be written as
cout << format(translate("You have 1 file in the directory", plural("You have {1} files in the directory"),files)) % files << endl;
button->setLabel(translate(context("File"),"open"));
With this modification, the (w)gettext could all share the same names and there will be no need to use c-like names.
What you think?
This one more interesting. However there an important point to check:
Integration with xgettext - would it be able to read this or entire new xgettext should be developed to extract strings.
I don't understand. Could you clarify, please? For me all the gettext functions should share the same name as well as all all the wgettext. No need to use the prefixed 'p' 'd' ...
I need to think about, probably it may be an alternative.
You could also associate the translate function to the context object button->setLabel(context("File").translate("open")); This can be extended to the domain, button->setLabel(domain("D").context("File").translate("open")); but doesn't scale well for the plural parameter. Best, Vicente
From: Vicente BOTET <vicente.botet@wanadoo.fr>
Message du 16/04/11 15:01 De : "Artyom"
I have made a diagonal reading and I find your library really interesting.
I
think I will spent quite more time reviewing it.
I have just a first minimal and formal remark. When I see the overloading of
the translate function
message boost::locale::translate (char const *msg) message boost::locale::translate (char const *context, char const *msg) message boost::locale::translate (char const *single, char const *plural, int
n) message boost::locale::translate (char const *context, char const *single,
char const *plural, int n) message boost::locale::translate (std::string const &msg) message boost::locale::translate (std::string const &context, std::string
const &msg) message boost::locale::translate (std::string const &context, std::string
const &single, std::string const &plural, int n) message boost::locale::translate (std::string const &single, std::string const
&plural, int n)
this let me think that it would be difficult to know know what is the message, the context, the domain, whether the message is the singular or plural form.
This is the general concept of how gettext used around. So I stick with its
conversion extending it, same concept used in Qt. It is quite common.
I agree that it is not perfect but it seems to be ok.
I'm sure that you will reach to provide something clearer that don't adhere to gettext (which is hidden for the user).
It is not really hidden user expected to use: gettext catalogs, gettext tools like msgfmt or xgettext, and use localization programs that support gettext like Lokalize or poedit. Also gettext fine but it has three major drawbacks that are solved by Boost.Locale - Support of multiple locales in same process - More permissive runtime (BSL vs LGPL) - Support of wide characters (wgettext)
The equivalent for (w)gettext uses the c-like idiom, i.e. uses different names.
std::string boost::locale::gettext (char const *id, std::locale const &loc=std::locale()) std::string boost::locale::ngettext (char const *s, char const *p, int n,
std::locale const &loc=std::locale()) std::string boost::locale::dgettext (char const *domain, char const *id, std::locale const &loc=std::locale()) std::string boost::locale::dngettext (char const *domain, char const *s, char
const *p, int n, std::locale const &loc=std::locale()) std::string boost::locale::pgettext (char const *context, char const *id,
std::locale const &loc=std::locale()) std::string boost::locale::npgettext (char const *context, char const *s, char
const *p, int n, std::locale const &loc=std::locale()) std::string boost::locale::dpgettext (char const *domain, char const *context,
char const *id, std::locale const &loc=std::locale()) std::string boost::locale::dnpgettext (char const *domain, char const *context, char const *s, char const *p, int n, std::locale const &loc=std::locale())
Neither is satisfying me.
These are mostly gettext compatibility functions so users familiar with gettext would find themselves with (almost) same API.
You are not forced to provide C-like interfaces in a Boost library to content some users that know the gettext interface. It is quite ugly.
translate and gettext have little bit different meaning. translate creates an object that is convertable to localized message according to targets's (stream) locale while gettext takes locale as parameter out << translate("Hello"); May be different from out << gettext("Hello"); As translate would use out's locale while gettext would use global locale. Also I do not see something wrong with gettext basic interface. Most users who ever used gettext are familiar with it.
I was wondering if the use of Boost.Parameters could help.
I'm not really familiar with Boost.Parameters but from quick glance it requires not-so trivial template metaprogramming but what is even more important I'm afraid that things like
translate(context_ = "File","Open")
I had no issue explaining this idiom to users of a library. Another question is for the implementer of the library, some more explanation will be needed.
May scary off some average C++ programmers that would not understand what is this thing
context_ = "File"
Finally I want Boost.Locale be used by not brilliant C++ programmers as well.
I know what hard times I have explaining about boost::bind to average C++ programmers so making things like that would not help too much.
Well, it is your library. It is up to you to maintain ugly interfaces like the preceding ones. From my side the add a -1 to the review. Fortunately there are a lot of positive parts.
I really like translate(context("File"),"Open") over the first. It is much clearer from user point of view.
could be written as
cout << format(translate("You have 1 file in the directory", plural("You have {1} files in the directory"),files)) % files << endl;
button->setLabel(translate(context("File"),"open"));
With this modification, the (w)gettext could all share the same names and
there will be no need to use c-like names.
What you think?
This one more interesting. However there an important point to check:
Integration with xgettext - would it be able to read this or entire new xgettext should be developed to extract strings.
I don't understand. Could you clarify, please? For me all the gettext functions should share the same name as well as all all the wgettext. No need to use the prefixed 'p' 'd' ...
I explain. Boost.Locale does not live alone. It requires other tools, for example nice programs like poedit or Lokalize to translate the messages. You should also use gettext binary tools: - xgettext - extracts the strings from sources and creates pot files useable for translators - msgfmt - convert po files to mo files - msgmerge - merge translated files with updated strings And much more. See: http://cppcms.sourceforge.net/boost_locale/html/messages_formatting.html#ext... Now xgettext tools know to handle C++ overloading well but I'm not sure if it would handle tranlsate(convert("File"),"Open"). When it handles translate("File","Open") well. So likely that means that boost_xgettext tool should be written (and this isn't that simple). So I'm not sure that users would be happy to work with two tools boost_xgettext and xgettext to extract messages from the files especially when the project uses gettext in may parts (including non-C++ ones) In any case I'll check this.
I need to think about, probably it may be an alternative.
You could also associate the translate function to the context object
button->setLabel(context("File").translate("open"));
This can be extended to the domain,
button->setLabel(domain("D").context("File").translate("open"));
but doesn't scale well for the plural parameter.
This way or other all these are attempts to overcome the limitation of C++ to have named parameters... Maybe it is something that should be solved at language level. I don't know. But in C++ we usually live without named parameters... It is a point to think about. And I don't currently have fast and simple solution. Best, Artyom
On 17.04.2011 0:17, Artyom wrote:
Boost.Locale does not live alone. It requires other tools, for example nice programs like poedit or Lokalize to translate the messages.
You should also use gettext binary tools:
- xgettext - extracts the strings from sources and creates pot files useable for translators - msgfmt - convert po files to mo files - msgmerge - merge translated files with updated strings
And much more.
See: http://cppcms.sourceforge.net/boost_locale/html/messages_formatting.html#ext...
...I guess (all) these instruments must be written (from scratch) and delivered as part of the Boost.Locale project, and placed among other Boost.Tools (bjam, bcp, wave, etc.) This eliminate dependencies from external (not under our control) tools (that we may re-implement in a better fashion)
[...]
So likely that means that boost_xgettext tool should be written (and this isn't that simple).
So I'm not sure that users would be happy to work with two tools boost_xgettext and xgettext [...]
-- - Do you speak English? Мужик с глубоким вздохом: - Yes I do. А хули толку?
Boost.Locale does not live alone. It requires other tools, for example nice programs like poedit or Lokalize to translate the messages.
You should also use gettext binary tools:
- xgettext - extracts the strings from sources and creates pot files useable for translators - msgfmt - convert po files to mo files - msgmerge - merge translated files with updated strings
And much more.
See:
http://cppcms.sourceforge.net/boost_locale/html/messages_formatting.html#ext...
...I guess (all) these instruments must be written (from scratch) and delivered as part of the Boost.Locale project, and placed among other Boost.Tools (bjam, bcp, wave, etc.)
This eliminate dependencies from external (not under our control) tools (that we may re-implement in a better fashion)
So please re-implement: - ICU library - Compiler - Operating System Boost does not live in empty space, it lives in the real world, it has too much tendency to reinvent the wheel. Artyom
Message du 16/04/11 08:04 De : "Vicente BOTET" A : boost@lists.boost.org Copie à : Objet : [boost] [locale] Review. Internationalization library?
As the review period has been extended, I will try to review at least the documentation.
I guess this has already been discussed, so if it is the case, please could you give me the pointer? Instead of providing new datetime, calendars classes I would preferred that you propose the needed modification to Boost.DateTime library, so it can be used in an internationalization context. Why have you preferred to redo Boost.DateTime? Do your classes preserve the same interface than Boost.DateTime? Best, Vicente
Message du 16/04/11 09:30 De : "Vicente BOTET" A : boost@lists.boost.org Copie à : Objet : Re: [boost] [locale] Review. Internationalization library?
Message du 16/04/11 08:04 De : "Vicente BOTET" A : boost@lists.boost.org Copie à : Objet : [boost] [locale] Review. Internationalization library?
As the review period has been extended, I will try to review at least the documentation.
I guess this has already been discussed, so if it is the case, please could you give me the pointer?
Instead of providing new datetime, calendars classes I would preferred that you propose the needed modification to Boost.DateTime library, so it can be used in an internationalization context.
Why have you preferred to redo Boost.DateTime?
If the DateTime library is redone, shouldn't it be released as a separated one, DateTime2?
Do your classes preserve the same interface than Boost.DateTime?
If not, does the documentation show the differences in a specific section? If we follow the Chrono design, shouldn't the calendar be a template parameter of the dattime class? What about rewriting the following date_time some_point = period::year * 1995 + period::january + period::day*1; as date_time some_point = year(1995) + january + day(1); ? Why your datatime class output by default as a number? Why there is no a default format? Best, Vicente
Why have you preferred to redo Boost.DateTime?
If the DateTime library is redone, shouldn't it be released as a separated one, DateTime2?
No, because they have very different purposes. There is almost no locale dependent libraries in Boost while boost::locale::date_time is strictly locale dependent. It provides same interface for different calendars and they may be changed in the runtime.
Do your classes preserve the same interface than Boost.DateTime?
If not, does the documentation show the differences in a specific section?
Actually almost everything there is different: http://cppcms.sourceforge.net/boost_locale/html/dates_times_timezones.html
If we follow the Chrono design, shouldn't the calendar be a template parameter of the dattime class?
What about rewriting the following
date_time some_point = period::year * 1995 + period::january + period::day*1;
as
date_time some_point = year(1995) + january + day(1);
?
Actually it may be good idea. I'm already thinking on improvement of date_time API due to issues rise in the review and it seems that it may be one of the approaches,
Why your datatime class output by default as a number? Why there is no a default format?
Because date_time is approximately a number that represents a time point in UTC (POSIX time) - seconds since Jan 1, 1970 GMT without leap seconds. But it under the hood it allows to perform date-time calculations according to current locale's rules. It outputs number because "it is a number of seconds since..." and the actual stream formatters are responsible to formatting it. It is covered by the links above. Basically there is a separation of roles: - date_time calculates times - iostream formats numbers - numeric representation connects between them.
Best, Vicente
Thanks for the comments, Artyom
Message du 16/04/11 15:22 De : "Artyom" A : boost@lists.boost.org Copie à : Objet : Re: [boost] [locale] Review. Internationalization library?
Why have you preferred to redo Boost.DateTime?
If the DateTime library is redone, shouldn't it be released as a separated one, DateTime2?
No, because they have very different purposes.
There is almost no locale dependent libraries in Boost while boost::locale::date_time is strictly locale dependent.
It provides same interface for different calendars and they may be changed in the runtime.
I think that internationalization is a traversal concern that could be applied to a lot of libraries. For example, it could be applied to Boost.Ratio, Boost.Chrono, Boost.Units. This doesn't means that all these libraries must be inside Boost.Locale/I18N. So yes, I'm sure that it will be better you provide a separate proposal for, let me say, Boost.Calendar or Boost.Dates that will use whatever is needed to make dates, calendars internationalizable.
Do your classes preserve the same interface than Boost.DateTime?
If not, does the documentation show the differences in a specific section?
Actually almost everything there is different:
http://cppcms.sourceforge.net/boost_locale/html/dates_times_timezones.html
I see this know.
If we follow the Chrono design, shouldn't the calendar be a template parameter of the dattime class?
What about rewriting the following
date_time some_point = period::year * 1995 + period::january + period::day*1;
as
date_time some_point = year(1995) + january + day(1);
?
Actually it may be good idea. I'm already thinking on improvement of date_time API due to issues rise in the review and it seems that it may be one of the approaches,
Why your datatime class output by default as a number? Why there is no a default format?
Because date_time is approximately a number that represents a time point in UTC (POSIX time) - seconds since Jan 1, 1970 GMT without leap seconds.
boost::time_point<> is also an opaque number. This doesn't mean that it is anumber. This doesn't explain why a default other than a raw number is not better. I would expect that it outputs as a date + a day time.
But it under the hood it allows to perform date-time calculations according to current locale's rules.
It outputs number because "it is a number of seconds since..." and the actual stream formatters are responsible to formatting it.
It is covered by the links above.
Basically there is a separation of roles:
- date_time calculates times - iostream formats numbers - numeric representation connects between them.
I don't see an explanation to choose as default the hidden representation. By the way, i would be interested in adapting Boost.Chrono to use Boost.Locale/I18N. Maybe a future Boost.Calendar library would use Boost.Chrono. Best, Vicente
From: Vicente BOTET <vicente.botet@wanadoo.fr>
De : "Artyom"
Why have you preferred to redo Boost.DateTime?
If the DateTime library is redone, shouldn't it be released as a separated
one, DateTime2?
No, because they have very different purposes.
There is almost no locale dependent libraries in Boost while boost::locale::date_time is strictly locale dependent.
It provides same interface for different calendars and they may be changed in
the runtime.
I think that internationalization is a traversal concern that could be applied to a lot of libraries. For example, it could be applied to Boost.Ratio, Boost.Chrono, Boost.Units. This doesn't means that all these libraries must be inside Boost.Locale/I18N. So yes, I'm sure that it will be better you provide a separate proposal for, let me say, Boost.Calendar or Boost.Dates that will use whatever is needed to make dates, calendars internationalizable.
The real problem that if you need internationalizable calendar you will need ICU... Because it is damn hard to implement a dozen of different calendars: Hebrew, Islamic, Japanese, Chinese and so on and handle for all of them time-zone. Just for the record the time zone support in Boost.DateTime is broken. See: http://cppcms.sourceforge.net/boost_locale/html/dates_times_timezones.html#d... So how can I say... It would not be simple. Boost.Locale creates an abstract calendar for calendar operations and separate formatting facilities (including different calendars) via time point represented as POSIX time. Everything may be localized but the question how hard should you work.
Why your datatime class output by default as a number? Why there is no a default format?
Because date_time is approximately a number that represents a time point in UTC (POSIX time) - seconds since Jan 1, 1970 GMT without leap seconds.
boost::time_point<> is also an opaque number. This doesn't mean that it is anumber. This doesn't explain why a default other than a raw number is not better. I would expect that it outputs as a date + a day time.
Actually, in second thought I can change the default. It shouldn't be a big problem. Other reviewer requested this as well. I need only ensure that formatting flags would change it. Also small note, that may be little bit confusing: date_time hebrew_calendar_date = ...; output_with_gregorian_locale << hebrew_calendar_date Would display Gregorian date as the calendar is rendered in the context of the target stream's locale
Basically there is a separation of roles:
- date_time calculates times - iostream formats numbers - numeric representation connects between them.
I don't see an explanation to choose as default the hidden representation.
Numeric is just most universal one. But I think I'll change the default. (note above)
By the way, i would be interested in adapting Boost.Chrono to use Boost.Locale/I18N. Maybe a future Boost.Calendar library would use Boost.Chrono.
Actually it is sounds interesting. However Boost.Chrono has its own goals while boost.locale has different so we should think how to do it right in future. Best, Artyom
I guess this has already been discussed, so if it is the case, please could you give me the pointer?
Instead of providing new datetime, calendars classes I would preferred that you propose the needed modification to Boost.DateTime library, so it can be used in an internationalization context.
Why have you preferred to redo Boost.DateTime?
Few pointers: - http://cppcms.sourceforge.net/boost_locale/html/appendix.html#why_plain_numb... - http://cppcms.sourceforge.net/boost_locale/html/dates_times_timezones.html#d... Few points to differ: Boot.Locale date_time is: a) Provides different calendars (non-Gregorian) like Hebrew, Islamic that are frequently used using same interface. b) locale dependent (which calendar, what is first day of week) c) Time-Zone dependent (for example adding one hour is different from changing its posix time by +3600 because of Summer time) d) Represents both time and date in same object represented as a POSIX time Note: ptime is different as it is not really POSIX time it may be local time as well. Basically Boost.DateTime and Boost.Locale's date_time have very few in common. Boost.Locale's date_time is like a calculator of time in current locale.
Do your classes preserve the same interface than Boost.DateTime?
No, it does not. It is very different.
Best, Vicente _______________________________________________ Unsubscribe & other changes:
Message du 16/04/11 15:11 De : "Artyom" A : boost@lists.boost.org Copie à : Objet : Re: [boost] [locale] Review. Internationalization library?
I guess this has already been discussed, so if it is the case, please could you give me the pointer?
Instead of providing new datetime, calendars classes I would preferred that you propose the needed modification to Boost.DateTime library, so it can be used in an internationalization context.
Why have you preferred to redo Boost.DateTime?
Few pointers:
- http://cppcms.sourceforge.net/boost_locale/html/appendix.html#why_plain_numb... - http://cppcms.sourceforge.net/boost_locale/html/dates_times_timezones.html#d...
Few points to differ:
Boot.Locale date_time is:
a) Provides different calendars (non-Gregorian) like Hebrew, Islamic that are frequently used using same interface.
b) locale dependent (which calendar, what is first day of week)
c) Time-Zone dependent (for example adding one hour is different from changing its posix time by +3600 because of Summer time)
d) Represents both time and date in same object represented as a POSIX time
Note: ptime is different as it is not really POSIX time it may be local time as well.
Basically Boost.DateTime and Boost.Locale's date_time have very few in common.
The domain, isn't it?
Boost.Locale's date_time is like a calculator of time in current locale.
Do your classes preserve the same interface than Boost.DateTime?
No, it does not. It is very different.
So, you have needed to change the interface completly. Have you take a look at Boost.Chrono? I'm sure that it will inspire to find a more open interface. Best, vicente
From: Vicente BOTET <vicente.botet@wanadoo.fr>
Boost.Locale's date_time is like a calculator of time in current locale.
Do your classes preserve the same interface than Boost.DateTime?
No, it does not. It is very different.
So, you have needed to change the interface completly. Have you take a look at Boost.Chrono? I'm sure that it will inspire to find a more open interface.
I'll take a look deeper on Boost.Chrono when I'll reevaluate the boost::locale::date_time API. Artyom
----- Original Message ----
From: Vicente BOTET <vicente.botet@wanadoo.fr> To: boost@lists.boost.org Sent: Sat, April 16, 2011 9:02:47 AM Subject: [boost] [locale] Review. Internationalization library?
Hi,
from the name of the library Boost.Locale and the section "What is Boost.Locale?" I didn't get enough information about the motivation and the scope of the library. I think that maybe be this is due to the fact that the dependency to ICU hides a lot of features the library provides. I think that a direct link to what ICU is is a must, but I would expect a little bit more than "On the other hand, there is a great, well debugged, high quality, widely used ICU library that gives all of the goodies" in this section.
I had completely rewritten this section. See: http://article.gmane.org/gmane.comp.lib.boost.devel/217866
From my side if the library was named Boost.Internationalization I'm sure I would had take a look long time ago. Do you think that this renaming (or a shorter one) will cover the whole library or there are parts of the library that don't fall in the internationalization domain?
Actually there are 3 terms: - Internationalization (i18n)- the preparation of the software to support different cultures - Localization (l10n) - adopting the software for specific culture. - Globalization - 118n+l10n (not really used outside Microsoft terminology) This way or other I'd prefer not to rename the library as there already users all around and I don't think it would benefit from it much. Especially that locale is quite short name.
As the review period has been extended, I will try to review at least the documentation.
Thanks. Artyom
Message du 16/04/11 14:48 De : "Artyom" A : boost@lists.boost.org Copie à : Objet : Re: [boost] [locale] Review. Internationalization library?
----- Original Message ----
From: Vicente BOTET To: boost@lists.boost.org Sent: Sat, April 16, 2011 9:02:47 AM Subject: [boost] [locale] Review. Internationalization library?
Hi,
from the name of the library Boost.Locale and the section "What is Boost.Locale?" I didn't get enough information about the motivation and the scope of the library. I think that maybe be this is due to the fact that the dependency to ICU hides a lot of features the library provides. I think that a direct link to what ICU is is a must, but I would expect a little bit more than "On the other hand, there is a great, well debugged, high quality, widely used ICU library that gives all of the goodies" in this section.
I had completely rewritten this section.
See: http://article.gmane.org/gmane.comp.lib.boost.devel/217866
It is not clear from this introduction that the library provide datetime and calendar classes independent from Boost.DateTime.
From my side if the library was named Boost.Internationalization I'm sure I would had take a look long time ago. Do you think that this renaming (or a shorter one) will cover the whole library or there are parts of the library that don't fall in the internationalization domain?
Actually there are 3 terms:
- Internationalization (i18n)- the preparation of the software to support different cultures - Localization (l10n) - adopting the software for specific culture. - Globalization - 118n+l10n (not really used outside Microsoft terminology)
This way or other I'd prefer not to rename the library as there already users all around and I don't think it would benefit from it much. Especially that locale is quite short name.
I insist Locale is on the other side of Internationalization, and you library is more about internationalization. If you want a short name what about i18n? By the way, I was unable to find the grammar of the formatted messages? This is an important part that the document must contain explicitly. Best, Vicente
From: Vicente BOTET <vicente.botet@wanadoo.fr>
De : "Artyom"
From: Vicente BOTET
from the name of the library Boost.Locale and the section "What is Boost.Locale?" I didn't get enough information about the motivation and the scope of the library. [snip]
I had completely rewritten this section.
See: http://article.gmane.org/gmane.comp.lib.boost.devel/217866
It is not clear from this introduction that the library provide datetime and calendar classes independent from Boost.DateTime.
Should it be a part of introduction? Also the fact that it supports non-Gregorian calendars should be "leading"
From my side if the library was named Boost.Internationalization I'm sure I would had take a look long time ago. Do you think that this renaming (or a shorter one) will cover the whole library or there are parts of the
library that don't fall in the internationalization domain?
Actually there are 3 terms:
- Internationalization (i18n)- the preparation of the software to support different cultures - Localization (l10n) - adopting the software for specific culture. - Globalization - 118n+l10n (not really used outside Microsoft terminology)
This way or other I'd prefer not to rename the library as there already users all around and I don't think it would benefit from it much. Especially that locale is quite short name.
I insist Locale is on the other side of Internationalization, and you library is more about internationalization. If you want a short name what about i18n?
It was one of potential names at the beginning but I had found that writing numbers (i18n) takes more time the to spell a native English word (locale)
By the way, I was unable to find the grammar of the formatted messages? his is an important part that the document must contain explicitly.
See: http://cppcms.sourceforge.net/boost_locale/html/localized_text_formatting.ht... I forgot to add how to insert "{" and "}" but it will be there (by adding "{{" and "}}" ) Best, Artyom
participants (3)
-
Artyom -
Max Sobolev -
Vicente BOTET