Apache OpenOffice (AOO) Bugzilla – Issue 48123
Auto-enabling of CTL needs improvement
Last modified: 2006-01-11 18:10:46 UTC
After installing OOo on Windows XP, with - Thai language group (complex script language collection) installed (using the "Supplemental language support" box on the "Languages" tab of "Regional and Language Settings") - Thai system locale (set in the "Language for non-Unicode programs" box on the "Advanced" tab of "Regional and Language Settings") - US English user locale (set on the "Regional Options" tab of "Regional and Language Settings") CTL support is not automatically enabled. This is a common configuration: there's no necessity for a Thai user to change the user locale from English to Thai, so it often isn't. There is a necessity for the Thai language group to be installed (otherwise a user can't type Thai). Also the system locale is nearly always set to Thai, because it enables use of grave accent for language switching. It seems that OOo currently considers only the user default locale in determining whether to enable CTL support. I think the most logical solution would be to enable CTL support by default if there is an installed complex script language group (using the Win32 IsValidLanguageGroup function).
The office does not look at the system locale settings for this at all - much less at wether any packages are installed into the system. As far as I can tell, we preselect CTL support, if any language pack for a Thai language is installed. Currently this is the case for locales th, hi-IN, ar and he, so this should be the case for a Thai version of OOo or if a Thai language pack is installed. In those cases we don't care for the users choice of UI locale nor for any system settings. Adding a more complicated inference mechanism would probably be a substantial change. BTW: This feature request is not very clear. By what condition should the office decide to preenable CTL support? IMHO such a rule should be useful for all CTL locales.Detecting that a certain package is installed into the system does not seem to be sufficient (what, if it is there to cater for the 2 people in a 1000-people company that need it?) and would also be fragile highly platform-dependent behavior. Similarly. the system locale does not seem to be a good choice. AFAICT it is by design that the system locale is a preselection, which the can override by their choice of user locale. That setting a certain system locale enables a certain system keyboard shortcut appears to be very specific to the operating environment (maybe even to certain versions). Is there any official platform documentation. that this is an interface that can used to detect the need for complex script support?
set target to 2.0.1
My feature request is that auto-enabling of CTL support is somehow enhanced so that on Windows it is automatically enabled in a situation where - the Thai language group is supported and installed, - the user locale is US, - the system locale is Thai, and - there is no Thai interface pack installed. The reason for this request is that this is a very common situation in Thailand. I am not sufficiently familiar with the internals of OOo to be sure what the right way to do this is. I don't think you analysis of the current behaviour is correct. If the user locale is Thai and there is no Thai language pack, then CTL support is enabled (and the option to disable it is greyed out). On Windows, the System Locale is a completely different thing from the User Locale; it's not like on Linux, where it's a default locale which can be overridden for each user. There's a separate Default User Locale which provides the default for a new user's User Locale. There's a good summary here: http://www.microsoft.com/globaldev/DrIntl/faqs/Locales.mspx Making the system locale be Thai allows that non-Unicode Thai applications to work on that system. The IsValidLanguageGroup function is documented here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_001c.asp Note that having a particular language group installed is a prerequisite for having a language in that group as a system or user locale. I can see two possible approaches: a) If any CTL language group is installed, enable CTL support b) If the system locale is a CTL language (which is only possible if a CTL language group is installed), enable CTL support These are both platform dependent, but I think determining whether to auto-enable CTL support is something that is inherently platform dependent. However, I don't see anything fragile: they are both accessible using officially documented APIs. The consequences of failing to enable CTL support when it is needed are much worse than those of enabling CTL support when it is not needed, so I would say that in a situation where it is uncertain whether CTL support is needed it is better by default to enable it (and allow the user to disable it if they do not in fact need it). That would lead to (a) rather than (b): if IsValidLanguageGroup() says that no CTL language group is installed, then it is 100% certain that the user cannot use a CTL language. (b) would be a more conservative change. I find it very hard to think of a situation where a user would not want CTL support enabled on a machine with a system locale that was a CTL language.
FT: This issue will sovled in a specification done for 42730. Please refer to this issue for solution. Thx. *** This issue has been marked as a duplicate of 42730 ***
closing duplicate.