Red Hat Bugzilla – Bug 195474
Chinese and Bengali pages are not translated correctly by RHN
Last modified: 2013-08-05 23:14:39 EDT
If a user sets his locale preference as either Chinese or Bengali, the pages are
still shown in English. If he instead sets his locale as "Use Browser Settings"
and has his browser settings set to Bengali or Chinese, the languages display
These bugs are elaborated in more detail in Bugzilla 192465 and 193811
fixed locale object....this affected any locale that also included a country
code (e.g zh_cn, zh_tw, bn_in).
mass move to on qa
QA Contact -> ssalevan
I've discovered that the following country codes translate to Chinese:
The following do not:
If this is intentional (dialects are different or whatnot) then I wouldn't worry
too much about it; however, if it's more of a locale issue you might want to
check it out.
Bengali pages do not translate whether my country code is bn or bn-IN; refer to
my comments in BZ# 193811 for some more info on this... I've made it block this
bug as they seem to deal with the same issue.
Due to this Bengali issue and so you can check up the whole Chinese thing, I've
moved this bug to FAILS_QA.
The Bengali locale issue should be fixed when the fix for bz 193811 hits QA. It
is fixed on my machine, at least.
The other issue with the various Chinese locales is a black hole which I think
we should avoid. This would require RHN to add partial locale matching based on
language code if no match exists for the full locale. This could cause a number
of problems including cultural interpretation issues and basic readability. In
some languages, there are dialects which are different enough to almost be
IMHO, if a user selects the a locale like zh_HK and gets English, that's OK post
application of the fix in bz 193811. That fix would allow the user to select zh
as a fallback locale and they would see Chinese text. This leave the user in
control of locale behavior instead of forcing RHN to guess the magcially correct
moving to ON_QA since we had minpush and 193811 appears to be VERIFIED.
Given Kevin's comments in comment #4 and the verification of 193811, it looks
like this issue is now resolved, so I'm moving this bug to VERIFIED.
closing -- currentrelease