Hello! I'm extremely happy about Boost.Locale, but I've found a few things lacking. So at first I wrote a some wrappers to get around a few flaws with my usage of Boost.Locale. One of these flaws was how it's hardcoded to use the Gettext directory hierarchy. I'd rather store my stuff in 'lang/en_US.mo' rather than 'lang/en_US/LC_MESSAGES/my_app.mo'. The patch adds a 'path format' feature, which allows you to format the directory structure when finding Gettext catalogs, to achieve the effect above. All you really have to do is run: gen.add_path_format("{1}/{2}.mo"); // Use a smaller hierarchy. to achieve the result that I prefer, or gen.add_path_format("{1}/{2}/{3}/{4}.mo"); // Use a Gettext hierarchy. to achieve the result that Boost.Locale uses right now. Ripped straight from Doxygen comments: {1} A path to search for catalogs in. {2} The locale's name. {3} The locale's category. {4} The Gettext domain. I'm new to submitting patches and things, and I'm not sure how I could make this feature better or even acceptable if it isn't already, but I'm sure it'd help others out there. There are a few drawbacks I've found with my code: - To be backwards compatible I've had to add some hackery to add the Gettext format if the path formats vector is empty. - Without consulting documentation, the format is unreadable. - I haven't tested it on the Win32 backend. I'm 90% sure the code would work, it's only 4 lines of code added and it's identical to the code added in the other backends, but it's still untested code. - It's not tested properly. By properly, I mean the tests past with adding a format, and falling back to the default format, but I haven't tried having a 'compact' format. I'm not sure if this would indicate a fault in the formatting code though, as that'd be the only difference code-wise, unless there's more code that has the Gettext hierarchy hardcoded, that didn't fail when I didn't fix the tests. The patch itself is based off of SVN r80097, and despite the diff being for r80104 I haven't tested it in that.. I did the work internally in Git but I made the patch using SVN, in case that matters. I've attached the patch, but I'm not sure how well that's going to go over considering I'm new to mailing lists, and I'm using.. Thunderbird.. Yeah. In case the attachment fails, it's available at http://sprunge.us/VSiX . I'd also like to know if it's appropriate to put '[patch]' in the title for any future patches, and if it should go after '[locale]' or at the end of the title. Thanks, Jookia.
Hello, First of all good job! This this is something that was requested for some time. However I have two points: 1. I'd rather use a single format and not multiple, such that I would use std::string generator::path_format() const void generator::path_format(std::string const &); void generator::set_default_path_format(); Because it makes a complex search that is even today complex even more complex. 2. I'd rather extend the template<typename CharType> message_format<CharType> *create_messages_facet(messages_info const &info); With an additional overload template<typename CharType> message_format<CharType> *create_messages_facet(messages_info const &info,std::string const &path_format); This way it would not affect Boost.Locale's ABI (changing sizeof of messages_info) 3. When you use format (format(path_formats[k]) % search_paths[i] % paths[j] % lc_cat % domain).str() It is better to call (format(path_formats[k]) % search_paths[i] % paths[j] % lc_cat % domain).str(std::locale::classic()) To prevent some problems with global locale or other stuff. Best Regards, Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/ ----- Original Message -----
From: Jookia <166291@gmail.com> To: boost@lists.boost.org Cc: Sent: Tuesday, August 21, 2012 5:43 AM Subject: [boost] [locale] Custom Gettext paths.
Hello!
I'm extremely happy about Boost.Locale, but I've found a few things lacking. So at first I wrote a some wrappers to get around a few flaws with my usage of Boost.Locale. One of these flaws was how it's hardcoded to use the Gettext directory hierarchy.
I'd rather store my stuff in 'lang/en_US.mo' rather than 'lang/en_US/LC_MESSAGES/my_app.mo'.
The patch adds a 'path format' feature, which allows you to format the directory structure when finding Gettext catalogs, to achieve the effect above. All you really have to do is run:
gen.add_path_format("{1}/{2}.mo"); // Use a smaller hierarchy.
to achieve the result that I prefer, or
gen.add_path_format("{1}/{2}/{3}/{4}.mo"); // Use a Gettext hierarchy.
to achieve the result that Boost.Locale uses right now. Ripped straight from Doxygen comments:
{1} A path to search for catalogs in. {2} The locale's name. {3} The locale's category. {4} The Gettext domain.
I'm new to submitting patches and things, and I'm not sure how I could make this feature better or even acceptable if it isn't already, but I'm sure it'd help others out there.
There are a few drawbacks I've found with my code:
- To be backwards compatible I've had to add some hackery to add the Gettext format if the path formats vector is empty.
- Without consulting documentation, the format is unreadable.
- I haven't tested it on the Win32 backend. I'm 90% sure the code would work, it's only 4 lines of code added and it's identical to the code added in the other backends, but it's still untested code.
- It's not tested properly. By properly, I mean the tests past with adding a format, and falling back to the default format, but I haven't tried having a 'compact' format. I'm not sure if this would indicate a fault in the formatting code though, as that'd be the only difference code-wise, unless there's more code that has the Gettext hierarchy hardcoded, that didn't fail when I didn't fix the tests.
The patch itself is based off of SVN r80097, and despite the diff being for r80104 I haven't tested it in that.. I did the work internally in Git but I made the patch using SVN, in case that matters. I've attached the patch, but I'm not sure how well that's going to go over considering I'm new to mailing lists, and I'm using.. Thunderbird.. Yeah. In case the attachment fails, it's available at http://sprunge.us/VSiX . I'd also like to know if it's appropriate to put '[patch]' in the title for any future patches, and if it should go after '[locale]' or at the end of the title.
Thanks, Jookia.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 21/08/12 18:52, Artyom Beilis wrote:
Hello,
First of all good job!
This this is something that was requested for some time.
Awesome and thanks. If this was requested previously, would there be a trac issue?
However I have two points: 1. I'd rather use a single format and not multiple, such that I would use
std::string generator::path_format() const void generator::path_format(std::string const &); void generator::set_default_path_format();
Because it makes a complex search that is even today complex even more complex.
This is something that I'm concerned about. If there's one path format, an application may have to do something 'interesting' if it has two paths with different formats. I'm all ears on how to fix this scenario: I have an application that is standalone that can run in /home, that uses the compact path. But it's also able to be installed system wide, which means it'd be best for it to use the /usr/share/locale thing. How would Of course, a single path format would solve a lot of problems I've mentioned so I'm happy to do that. I'm just a little concerned about that scenario.
2. I'd rather extend the
template<typename CharType> message_format<CharType> *create_messages_facet(messages_info const &info);
With an additional overload
template<typename CharType> message_format<CharType> *create_messages_facet(messages_info const &info,std::string const &path_format);
This way it would not affect Boost.Locale's ABI (changing sizeof of messages_info)
Ah, I'm new to ABIs and whatnot so I wasn't really paying attention. I'll get that done, but I'd also like to know about my concerns with the first issue, as this implies a single path.
3. When you use format
(format(path_formats[k]) % search_paths[i] % paths[j] % lc_cat % domain).str()
It is better to call
(format(path_formats[k]) % search_paths[i] % paths[j] % lc_cat % domain).str(std::locale::classic())
To prevent some problems with global locale or other stuff.
Alrighty. Thanks for your time, Jookia.
----- Original Message -----
From: Jookia <166291@gmail.com> To: boost@lists.boost.org Cc: Sent: Tuesday, August 21, 2012 8:55 PM Subject: Re: [boost] [locale] Custom Gettext paths.
On 21/08/12 18:52, Artyom Beilis wrote:
Hello,
First of all good job!
This this is something that was requested for some time.
Awesome and thanks.
If this was requested previously, would there be a trac issue?
I remember some were talking about it, but I assume it was not important enough to open a ticket.
However I have two points: 1. I'd rather use a single format and not multiple, such that I would use
std::string generator::path_format() const void generator::path_format(std::string const &); void generator::set_default_path_format();
Because it makes a complex search that is even today complex even more complex.
This is something that I'm concerned about. If there's one path format, an application may have to do something 'interesting' if it has two paths with different formats. I'm all ears on how to fix this scenario:
I have an application that is standalone that can run in /home, that uses the compact path. But it's also able to be installed system wide, which means it'd be best for it to use the /usr/share/locale thing. How would
Of course, a single path format would solve a lot of problems I've mentioned so I'm happy to do that. I'm just a little concerned about that scenario.
I see, multiple paths are ok as well.
2. I'd rather extend the
template<typename CharType> message_format<CharType> *create_messages_facet(messages_info const &info);
With an additional overload
template<typename CharType> message_format<CharType> *create_messages_facet(messages_info const &info,std::string const &path_format);
This way it would not affect Boost.Locale's ABI (changing sizeof of messages_info)
Ah, I'm new to ABIs and whatnot so I wasn't really paying attention. I'll get that done, but I'd also like to know about my concerns with the
first issue, as this implies a single path.
Than pass std::vector<std::string> const &path_formats instead of a single string.
3. When you use format
(format(path_formats[k]) % search_paths[i] % paths[j] % lc_cat % domain).str()
It is better to call
(format(path_formats[k]) % search_paths[i] % paths[j] % lc_cat % domain).str(std::locale::classic())
To prevent some problems with global locale or other stuff.
Alrighty.
Thanks for your time, Jookia.
Best and thanks for your effort! Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/
Okay, I've implemented some changes to the patch. The format call now uses the classic locale, and messages_info isn't changed. I feel that it's kind of repetitive and sloppy. Just a tiny bit. I don't see a way around it, though. I'm a newbie though. When using it in an application it feels a little odd to create a vector then pass that in to the create_messages_facet for a format when you're using a custom messages_info. As always I haven't tested a line of code of this on Windows, but I suspect it'd work. Thanks, Jookia.
----- Original Message -----
From: Jookia <166291@gmail.com>
Hi,
Okay, I've implemented some changes to the patch.
I'll apply it after several tweaks... You still need to have both create_message_facet(message_format const &) And create_message_facet(message_format const &,std::vector<std::string> const &paths) For backward compatibility.
The format call now uses the classic locale, and messages_info isn't changed.
Ok
I feel that it's kind of repetitive and sloppy. Just a tiny bit. I don't see a way around it, though. I'm a newbie though.
When using it in an application it feels a little odd to create a vector then pass that in to the create_messages_facet for a format when you're using a custom messages_info.
It is internal interface - that designed for locale backend writers and for some very specific custom uses like in-memory file system. So users expect to call generator::...
As always I haven't tested a line of code of this on Windows, but I suspect it'd work.
These are what unit tests for :-)
Thanks, Jookia.
Thanks, If you don't mind open a ticket so I will not forget. I'll try to take a look on it this weekend. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/
On 23/08/12 14:53, Artyom Beilis wrote:
----- Original Message ----- I'll apply it after several tweaks...
You still need to have both
create_message_facet(message_format const &)
And
create_message_facet(message_format const &,std::vector<std::string> const &paths)
For backward compatibility.
Is that for the ABI or something? As right now I have the format_paths argument default to an empty vector. Also, wouldn't that mean I'd have to duplicate all the template declarations too?
Thanks,
If you don't mind open a ticket so I will not forget. I'll try to take a look on it this weekend.
Alrighty.
----- Original Message -----
From: Jookia <166291@gmail.com> To: boost@lists.boost.org Cc: Sent: Thursday, August 23, 2012 7:57 AM Subject: Re: [boost] [locale] Custom Gettext paths.
On 23/08/12 14:53, Artyom Beilis wrote:
----- Original Message ----- I'll apply it after several tweaks...
You still need to have both
create_message_facet(message_format const &)
And
create_message_facet(message_format const &,std::vector<std::string> const &paths)
For backward compatibility.
Is that for the ABI or something? As right now I have the format_paths argument default to an empty vector. Also, wouldn't that mean I'd have to duplicate all the template declarations too?
Actually for both API and ABI Also I can handle it, no problem.
Thanks,
If you don't mind open a ticket so I will not forget. I'll try to take a look on it this weekend.
Alrighty.
Thanks! Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/
On 23/08/12 16:03, Artyom Beilis wrote:
----- Original Message -----
From: Jookia <166291@gmail.com> To: boost@lists.boost.org Cc: Sent: Thursday, August 23, 2012 7:57 AM Subject: Re: [boost] [locale] Custom Gettext paths.
On 23/08/12 14:53, Artyom Beilis wrote:
----- Original Message ----- I'll apply it after several tweaks...
You still need to have both
create_message_facet(message_format const &)
And
create_message_facet(message_format const &,std::vector<std::string> const &paths)
For backward compatibility.
Is that for the ABI or something? As right now I have the format_paths argument default to an empty vector. Also, wouldn't that mean I'd have to duplicate all the template declarations too?
Actually for both API and ABI
Also I can handle it, no problem.
Thanks, also here's the ticket: https://svn.boost.org/trac/boost/ticket/7266 After this happens I look forward to fixing a few other things, which I've found lacking.
----- Original Message -----
From: Jookia <166291@gmail.com> To: boost@lists.boost.org Cc: Sent: Thursday, August 23, 2012 9:12 AM Subject: Re: [boost] [locale] Custom Gettext paths.
On 23/08/12 16:03, Artyom Beilis wrote:
----- Original Message -----
From: Jookia <166291@gmail.com> To: boost@lists.boost.org Cc: Sent: Thursday, August 23, 2012 7:57 AM Subject: Re: [boost] [locale] Custom Gettext paths.
On 23/08/12 14:53, Artyom Beilis wrote:
----- Original Message ----- I'll apply it after several tweaks...
You still need to have both
create_message_facet(message_format const &)
And
create_message_facet(message_format const &,std::vector<std::string> const &paths)
For backward compatibility.
Is that for the ABI or something? As right now I have the format_paths argument default to an empty vector. Also, wouldn't that mean I'd have to duplicate all the template declarations too?
Actually for both API and ABI
Also I can handle it, no problem.
Thanks, also here's the ticket:
Thanks
After this happens I look forward to fixing a few other things, which I've found lacking.
What things? Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/
On 23/08/12 16:17, Artyom Beilis wrote:
After this happens I look forward to fixing a few other things, which I've found lacking.
What things?
Right now I'm trying to refrain from trying to suggest solutions to problems I don't fully understand. That said, right now there's no way to tell what locale you get out of Boost.Locale. You can pass in a bad locale and get out a good one, while still under the guise of a good one with no way to tell. For example, if I pass an ICU calender variant and it doesn't work (probably because the backend isn't ICU or some other matter), Boost.Locale still returns the locale with the variant name in it. This all works fine, and is expected behaviour in ICU from what I've read, but due to it it means I can't tell bad locales from good locales in my program. So if I write 'gen("BAD_US")' or something along the lines (my application test cases found this), chances are it'll come out fine. I don't know if it's possible, but I'd propose a function like get_real_locale_name which returns the 'real' name, as in the actual locale that's being used (as in a fall back if parts of the locale are valid), or an empty string if the locale is invalid all together. get_real_locale("en_US.UTF-8") == "en_US.UTF-8" get_real_locale("en_US.UTF-8@calender=asdfbadinputjkl") == "en_US.UTF-8" get_real_locale("zh_CN.UTF-24") == "" It seems fine, but I'm not sure if it's implementable. Briefly looking through ICU's documentation I don't really know if there's a way to get results like this. Now, this may seem irrelevant. But my second problem is being able to figure out the fields of a locale. Currently we have loc::info, but that returns garbage in, ICU falls back, garbage out despite ICU falling back and everything behaving nice. Also for brownie points, I'm not sure exactly how to get Gettext information from a locale that already exists, since it's not really documented from what I know. I'm still a newbie to the library. Another small thing, which is probably intended in libstdc++, is that locale generation will break if you have junk in LC_MESSAGES. It's kind of a far out thing, but I like to be able to set my translations separately to my locale, so I use the LC_MESSAGES environmental variable to read in to my messages_info. I'm pretty sure this is application-specific, but at this point I'm just reading through my code to see what workarounds I have. The tiniest thing that I can even think of is that I have a method like this in my application's code: string makeLocaleName(string const& language, string const& country, string const& encoding, string const& variant) { string name = language; if(country != "") { name += "_" + country; } if(encoding != "") { name += "." + encoding; } if(variant != "") { name += "@" + variant; } return name; } For convenience. It kind of compliments loc::info. So yeah, that's just just a bit of a garbled response because I'm not sure about any of it, and I'm sure a lot of it is by design, and it's probably just my nitpicking. Thanks, Jookia.
----- Original Message -----
From: Jookia <166291@gmail.com> To: boost@lists.boost.org Cc: Sent: Thursday, August 23, 2012 9:34 AM Subject: Re: [boost] [locale] Custom Gettext paths.
On 23/08/12 16:17, Artyom Beilis wrote:
After this happens I look forward to fixing a few other things, which I've found lacking.
What things?
Right now I'm trying to refrain from trying to suggest solutions to problems I don't fully understand. That said, right now there's no way to tell what locale you get out of Boost.Locale. You can pass in a bad locale and get out a good one, while still under the guise of a good one with no way to tell.
For example, if I pass an ICU calender variant and it doesn't work (probably because the backend isn't ICU or some other matter), Boost.Locale still returns the locale with the variant name in it. This all works fine, and is expected behaviour in ICU from what I've read, but due to it it means I can't tell bad locales from good locales in my program.
So if I write 'gen("BAD_US")' or something along the lines (my application test cases found this), chances are it'll come out fine.
Boost.Locale tries to gradually fallback to some supported locale, for example of you use Boost.Locale on FreeBSD without ICU using libstdc++ that only supported locales would be C or POSIX. On the other hand you should still be able to use encoding conversions and dictionaries. Maybe the numbers and dates would not be formatted according to the locale, but the messages would still work.
I don't know if it's possible, but I'd propose a function like get_real_locale_name which returns the 'real' name, as in the actual locale that's being used (as in a fall back if parts of the locale are valid), or an empty string if the locale is invalid all together.
get_real_locale("en_US.UTF-8") == "en_US.UTF-8" get_real_locale("en_US.UTF-8@calender=asdfbadinputjkl") == "en_US.UTF-8" get_real_locale("zh_CN.UTF-24") == ""
"Real-locale name" is backend dependent and not always 1-to-1 conversion. So you can assume that the name you had given is the locale name, however some flags may be ignored.
It seems fine, but I'm not sure if it's implementable. Briefly looking through ICU's documentation I don't really know if there's a way to get results like this.
Even with ICU the locale name would not be 1-to-1 conversion
Now, this may seem irrelevant. But my second problem is being able to figure out the fields of a locale. Currently we have loc::info, but that returns garbage in, ICU falls back, garbage out despite ICU falling back and everything behaving nice.
What do you mean, do you have an example? locale::info parses locale names syntactically.
Also for brownie points, I'm not sure exactly how to get Gettext information from a locale that already exists, since it's not really documented from what I know. I'm still a newbie to the library.
boost::locale::info gives you this information.
Another small thing, which is probably intended in libstdc++, is that locale generation will break if you have junk in LC_MESSAGES.
Boost locale does not use environment variable LC_MESSAGES, unlike POSIX locales Boost.Locale does not break down to different categories. The order the locale name is taken is LANG, LC_ALL, LC_CTYPE (if I remember correctly)
It's kind of a far out thing, but I like to be able to set my translations separately to my locale, so I use the LC_MESSAGES environmental variable to read in to my messages_info. I'm pretty sure this is application-specific, but at this point I'm just reading through my code to see what workarounds I have.
The tiniest thing that I can even think of is that I have a method like this in my application's code:
string makeLocaleName(string const& language, string const& country, string const& encoding, string const& variant) { string name = language;
if(country != "") { name += "_" + country; } if(encoding != "") { name += "." + encoding; } if(variant != "") { name += "@" + variant; }
return name; }
For convenience. It kind of compliments loc::info.
Good point.
So yeah, that's just just a bit of a garbled response because I'm not sure about any of it, and I'm sure a lot of it is by design, and it's probably just my nitpicking.
Thanks, Jookia.
Regards, Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/
On 26/08/12 21:16, Artyom Beilis wrote:
Boost.Locale tries to gradually fallback to some supported locale, for example of you use Boost.Locale on FreeBSD without ICU using libstdc++ that only supported locales would be C or POSIX.
On the other hand you should still be able to use encoding conversions and dictionaries. Maybe the numbers and dates would not be formatted according to the locale, but the messages would still work.
I don't know if it's possible, but I'd propose a function like get_real_locale_name which returns the 'real' name, as in the actual locale that's being used (as in a fall back if parts of the locale are valid), or an empty string if the locale is invalid all together.
get_real_locale("en_US.UTF-8") == "en_US.UTF-8" get_real_locale("en_US.UTF-8@calender=asdfbadinputjkl") == "en_US.UTF-8" get_real_locale("zh_CN.UTF-24") == ""
"Real-locale name" is backend dependent and not always 1-to-1 conversion.
So you can assume that the name you had given is the locale name, however some flags may be ignored. ...
What do you mean, do you have an example? locale::info parses locale names syntactically.
Hmm. Is it an exceptional case then that I can generate a locale with the name 'BAD' then, and get a locale out that acts like English but has the name 'BAD'? Is this an implementation detail? I'm not an expert or even knowledgeable, so I guess I should ask: Does this matter? Knowing what locale I'm actually using. Right now it seems to just be an issue for code correctness, or something like trying to open a specific file and having to check if the locale is valid, or using the locale's name. Opening 'data/<locale name>/images/logo.png' or something might end up bad with the BAD locale although it's English. Another way to prevent my program from using 'bad' data, is to figure out if the locale is valid. So, is there a way to test if a locale is valid, without it falling back? I see that the 'BAD' locale will fall back to 'en'. Oh, and if this is bad practice to be pedantic about this topic, I'd like to know so I can stop. It's just that in my unit tests, I can't actually say if the locale I've created is the locale I wanted. So maybe I'm approaching the problem wrong?
boost::locale::info gives you this information.
It does? All I see is the language, country, variant, encoding and name. This doesn't include the Gettext translation name or the domain.
Another small thing, which is probably intended in libstdc++, is that locale generation will break if you have junk in LC_MESSAGES.
Boost locale does not use environment variable LC_MESSAGES, unlike POSIX locales Boost.Locale does not break down to different categories. The order the locale name is taken is LANG, LC_ALL, LC_CTYPE (if I remember correctly)
Ah, so this is probably something to do with Linux then.
Regards, Artyom Beilis
Thanks for you time, Jookia.
----- Original Message -----
From: Jookia <166291@gmail.com> To: boost@lists.boost.org Cc: Sent: Sunday, August 26, 2012 2:55 PM Subject: Re: [boost] [locale] Custom Gettext paths.
Boost.Locale tries to gradually fallback to some supported locale, for example of you use Boost.Locale on FreeBSD without ICU using libstdc++ that only supported locales would be C or POSIX.
On the other hand you should still be able to use encoding conversions and dictionaries. Maybe the numbers and dates would not be formatted according to the locale, but the messages would still work.
I don't know if it's possible, but I'd propose a function
On 26/08/12 21:16, Artyom Beilis wrote: like
get_real_locale_name which returns the 'real' name, as in the actual locale that's being used (as in a fall back if parts of the locale are valid), or an empty string if the locale is invalid all together.
get_real_locale("en_US.UTF-8") == "en_US.UTF-8" get_real_locale("en_US.UTF-8@calender=asdfbadinputjkl") == "en_US.UTF-8" get_real_locale("zh_CN.UTF-24") == ""
"Real-locale name" is backend dependent and not always 1-to-1 conversion.
So you can assume that the name you had given is the locale name, however some flags may be ignored. ...
What do you mean, do you have an example? locale::info parses locale names syntactically.
Hmm. Is it an exceptional case then that I can generate a locale with the name 'BAD' then, and get a locale out that acts like English but has the name 'BAD'? Is this an implementation detail?
No, that means if you want to translate your application to the language that is not supported by the backend, you can.
I'm not an expert or even knowledgeable, so I guess I should ask: Does this matter? Knowing what locale I'm actually using. Right now it seems to just be an issue for code correctness, or something like trying to open a specific file and having to check if the locale is valid, or using the locale's name. Opening 'data/<locale name>/images/logo.png' or something might end up bad with the BAD locale although it's English.
Another way to prevent my program from using 'bad' data, is to figure out if the locale is valid. So, is there a way to test if a locale is valid, without it falling back? I see that the 'BAD' locale will fall back to 'en'.
You do this differently, you use gettext... std::string path = "data/" + gettext("en") + "/images/logo.png" And this way if the application is not translated to the locale's language it would get a logo from English locale, otherwise it would get the logo from the supported locale... More than that if the OS/backend does not support your locale you will still be able to get the correct logo - even if you translate the application to ancient Egyptian which should be "bad" for all means.
Oh, and if this is bad practice to be pedantic about this topic, I'd like to know so I can stop. It's just that in my unit tests, I can't actually say if the locale I've created is the locale I wanted. So maybe I'm approaching the problem wrong?
No, you can't for example if you are using for example ru_RU.UTF-8 locale with POSIX backend, it would work on your machine but on some other ru_RU locale would not be configured and will not be loaded. This is something that is done in the run time, but yet you prefer to run the application rather than fail. Also it is not always possible to know if it 100% loaded. For example even in ICU backend under some locales the spellout would not actually spell because of lack of relevant CLDR data - and this happens even with common locales like Austrian (AFAIR) So should you "fail" or continue? Some locales may be not official but they are relevant, for example is there es_US.UTF-8 locale? (I don't actually know) but, Spanish is not official language of USA, so should such a locale fail or it is fine? What is actually failure, is it partial or full or what?
boost::locale::info gives you this information.
It does? All I see is the language, country, variant, encoding and name. This doesn't include the Gettext translation name or the domain.
Domain is what you actually know - this is your application name :-)
Thanks for you time, Jookia.
You are welcome. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/
participants (2)
-
Artyom Beilis -
Jookia