Bug 801825 - detect_locale should handle a wider range of strings
detect_locale should handle a wider range of strings
Product: CloudForms Cloud Engine
Classification: Red Hat
Component: aeolus-conductor (Show other bugs)
Unspecified Unspecified
unspecified Severity low
: rc
: ---
Assigned To: Imre Farkas
: Triaged
: 811877 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2012-03-09 10:22 EST by Matt Wagner
Modified: 2014-08-17 18:27 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
The detect_locale function in Cloud Engine could not match nor order certain locales for languages. This bug fix widens the range of string detection for locale names.
Story Points: ---
Clone Of:
Last Closed: 2012-12-04 09:58:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2012:1516 normal SHIPPED_LIVE CloudForms Cloud Engine 1.1 update 2012-12-04 14:51:45 EST

  None (edit)
Description Matt Wagner 2012-03-09 10:22:55 EST
Description of problem:
This BZ is actually tracking two related problems in detect_locale:

1.) An intermittent error, "undefined method `<=>' for :"fr-FR":Symbol". We should probably make both both the user's requested languages _and_ I18n.available_locales return strings for easier comparison. Currently we cast the user's locales to symbols (to match available_locales), but you apparently cannot sort symbols.

2.) detect_locales currently doesn't do anything intelligent with country-specific locales. If you request "fr-FR" and we have "fr" available, we don't consider it a match since we're just comparing strings for equality. It's unclear to me whether we will ever want to support these country-specific versions (e.g., have an en-US and an en-GB to cover the minor differences, like "color" vs. "colour"). If we want to support them, we should probably be smarter -- if you request en-GB, "en" should suffice. Alternatively, if we *don't* think we will ever have region-specific dialects, we could just strip them off of the incoming languages -- if I request "en-US", just take it as "en".

A third nit is that if _none_ of your languages match (i.e., there is no intersection between my ACCEPT_LANGUAGE settings and what the app has translations for), we end up assigning the locale to nil. It seems like we fall back on the default locale in this case and everything works fine, but it feels like potentially sloppy code. (I wrote it, so I can say that. *grin*)
Comment 1 Imre Farkas 2012-03-13 06:45:43 EDT
Patch has been posted: https://fedorahosted.org/pipermail/aeolus-devel/2012-March/009544.html
Comment 2 Imre Farkas 2012-03-14 09:29:23 EDT
This issue has been fixed. Please verify the commit 7dc0c497d9c6d8ceef910f120af2ed47df2a64b3
Comment 3 Steve Linabery 2012-04-12 17:36:41 EDT
7dc0c497d9c6d8ceef910f120af2ed47df2a64b3 is only in master branch as of this writing.
Comment 4 Dave Johnson 2012-05-07 13:55:06 EDT
*** Bug 811877 has been marked as a duplicate of this bug. ***
Comment 6 Rehana 2012-10-26 03:30:36 EDT
Retested this bug 

By passing below language option from Firefox (for French)


Observed that all the time the conductor was accessible in French language

When tested with the language option "Arabic[ar]", observed that the conductor was loaded with default locale which is English

Moving the bug to verified


rpm -qa | grep aeolus
Comment 8 errata-xmlrpc 2012-12-04 09:58:21 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.