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 correctly. 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: zh-tw zh-cn The following do not: zh-sh zh-hk 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 separate languages. 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 locale.
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