Bug 801825

Summary: detect_locale should handle a wider range of strings
Product: [Retired] CloudForms Cloud Engine Reporter: Matt Wagner <matt.wagner>
Component: aeolus-conductorAssignee: Imre Farkas <ifarkas>
Status: CLOSED ERRATA QA Contact: Rehana <redakkan>
Severity: low Docs Contact:
Priority: unspecified    
Version: 1.0.0CC: akarol, athomas, cpelland, deltacloud-maint, dmacpher, hbrock, ifarkas, morazi, redakkan, slinaber, ssachdev
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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: Environment:
Last Closed: 2012-12-04 14:58:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Matt Wagner 2012-03-09 15:22:55 UTC
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 10:45:43 UTC
Patch has been posted: https://fedorahosted.org/pipermail/aeolus-devel/2012-March/009544.html

Comment 2 Imre Farkas 2012-03-14 13:29:23 UTC
This issue has been fixed. Please verify the commit 7dc0c497d9c6d8ceef910f120af2ed47df2a64b3

Comment 3 Steve Linabery 2012-04-12 21:36:41 UTC
7dc0c497d9c6d8ceef910f120af2ed47df2a64b3 is only in master branch as of this writing.

Comment 4 Dave Johnson 2012-05-07 17:55:06 UTC
*** Bug 811877 has been marked as a duplicate of this bug. ***

Comment 6 Rehana 2012-10-26 07:30:36 UTC
Retested this bug 

By passing below language option from Firefox (for French)

Fr,fr-be,fr-ca

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

on

rpm -qa | grep aeolus
aeolus-configure-2.8.9-1.el6cf.noarch
aeolus-conductor-0.13.21-1.el6cf.noarch
rubygem-aeolus-cli-0.7.6-1.el6cf.noarch
aeolus-conductor-doc-0.13.21-1.el6cf.noarch
aeolus-all-0.13.21-1.el6cf.noarch
rubygem-aeolus-image-0.3.0-12.el6.noarch
aeolus-conductor-daemons-0.13.21-1.el6cf.noarch

Comment 8 errata-xmlrpc 2012-12-04 14:58:21 UTC
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.

http://rhn.redhat.com/errata/RHEA-2012-1516.html