Issue 48123 - Auto-enabling of CTL needs improvement
Summary: Auto-enabling of CTL needs improvement
Status: CLOSED DUPLICATE of issue 42730
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: 680m95
Hardware: All Windows XP
: P3 Trivial (vote)
Target Milestone: OOo 2.0.1
Assignee: falko.tesch
QA Contact: issues@framework
Keywords: oooqa
Depends on:
Blocks: 42730
  Show dependency tree
Reported: 2005-04-25 16:30 UTC by jjc
Modified: 2006-01-11 18:10 UTC (History)
5 users (show)

See Also:
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description jjc 2005-04-25 16:30:35 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).
Comment 1 joerg.barfurth 2005-05-03 08:52:05 UTC
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

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?

Comment 2 Martin Hollmichel 2005-05-11 16:36:06 UTC
set target to 2.0.1
Comment 3 jjc 2005-05-19 18:03:16 UTC
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:

Making the system locale be Thai allows that non-Unicode Thai applications to
work on that system.

The IsValidLanguageGroup function is documented here:

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.

Comment 4 falko.tesch 2005-09-20 05:05:41 UTC
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 ***
Comment 5 lohmaier 2006-01-11 18:10:46 UTC
closing duplicate.