Issue 89147

Summary: Wrong Language in Tools/Language
Product: General Reporter: jackbassv <jackbassv>
Component: uiAssignee: AOO issues mailing list <issues>
Status: UNCONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: elish, issues, khirano, maho.nakata, thomas.lange
Version: DEV300_m10Keywords: needhelp
Target Milestone: ---   
Hardware: PC   
OS: Windows Vista   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---

Description jackbassv 2008-05-08 01:18:46 UTC
I selected Japanese as the asian language I want - I'm studying Japanese at the 
moment.

In Tools/Language, you get the options for "Hangul/Hanji Conversion" and 
"Chinese Translation", whereas I should be getting Kana/Kanji Conversion and 
Japanese Translation (or nothing).

Under Format/Change Case, Hiragana and Katakana appear as expected.

NOTE: This issue also appears in 2.4
Comment 1 conte4313 2009-03-20 21:09:57 UTC
I get the same issue (I'm also learning Japanese). 

I also notice when you end up selecting the "Chinese Translation", under 
"Tools --> Options --> Language Settings --> Language" the "Default Languages
for Documents" for "Asian" is reset from "Japanese" to "Chinese(simplified)" and
the Format --> Change Case options are still Hiragana and Katakana, even though
the default Asian language has been reset to Chinese.

I'm using a recent build of OpenOffice (v 3.0.0) Writer on Vista, although I
believe the latest version is now 3.0.1, I haven't tested it there.

Since this feature doesn't really affect the overall functionality and
robustness of OpenOffice writer and seeing how most people who use OpenOffice
probably speak and write in english, this probably wouldn't be considered a very
high priority issue unfortunately. Nonetheless, it's still an ideal feature if
OpenOffice products are to be used by anyone.

Perhaps Japanese is yet to be fully implemented and OpenOffices assumes Chinese
is the Default Language for Asian or this is a serious bug.

Ideas for future testing would be to try to see if other Asian languages are
fully implemented or even common European languages like Italian or French.
Comment 2 Mathias_Bauer 2010-05-17 15:37:15 UTC
Thomas, any opinion about this one?
Comment 3 thomas.lange 2010-05-18 09:04:58 UTC
AFAIR everything is according to spec.

a) As for why Katakana/Hiragana is only listed under 'Format/Change case' has
probably historic reasons. (You need to ask UX about that.) The only real
difference I see is that Katakana/Hiragana is implemented via simple calls to
the transliteration function of the break-iterator, whereas Hangul/Hanja and
Chinese conversion are too complex to be handled that simple and thus each have
their own dialog and implementation.
Another reason is that without a selection Hiragana/Katakana conversion operates
on a single word (like everything else in that submenu), whereas the ones for
Korean and Chinese text will operate on the whole document.

b) About why Chinese translation is available in the menu even even though the
underlying text is Japanese (or even English) and similar issues:
The spec for Asian language support defines all of them to be enabled if and
only if Asian languages are enable in the 'Options/Language Settings/Languages'
dialog.
That is because those options being enabled or disabled depending on the current
selection is too troublesome if you think about documents with hundreds of pages
of text.
It would require to iterate over all the text in the selection just too check if
the text does contain at least one character of Chinese, Japanese or
respectively Korean text. Also if no selection is set the Hangul/Hanja and
Chinese translation are to operate on the whole text, that is the whole document
hast to be checked for respective occurrences. 
At lest at the time those conversions were implemented the power of most
computers has been considered to be too small to handle this in a reasonable
time frame for large documents. And even nowadays I believe some user to have
pretty limited hardware.

c) About the default language being changed to Chinese after applying Chinese
conversion: That should also be part of the spec since even text that gets its
language attribute from the default language needs to be Chinese after executing
the conversion. The reasoning for this is that if you had e.g. a Chinese
document that got the wrong Asian language attribute after calling the
conversion all the text should be Chinese, even the text that was not in
Chinese! The goal of this is that new typed Chinese text will also always get
the Chinese language attribute, which might otherwise not always be the case if
a text portion gets extended that might have been left with a non Chinese Asian
language attribute (even if that would be only the default Asian language).
Consider for example a Western number or space that would have been left with a
default Asian language set to Korean.
However the changing of the default document language should apply to the
current document only.


Thus, all in all, I do not see anything stated in this issue that does not work
as defined. That is, if anything should be changed because of this issue, at
least the issue type should be set to something more appropriate than 'defect'.
Comment 4 Mathias_Bauer 2010-05-18 10:52:42 UTC
It seems that at least everything works as designed. This doesn't mean that the
design is correct. But the design isn't what is made in development only. Thus I
reassign this issue to someone from the ux team.

Frank, please either handle this issue or forward it to the ux discussion list.