Локализация ООО3.3.0 и интеграция расширений в меню [РЕШЕНО, Issue 114078]

[Yakov]

Столкнулся со следующей проблемой
ООО 3.3.0 beta 1 (ПРОБЛЕМА НАБЛЮДАЕТСЯ И В ООо-DEV 3.0.0 m85)
Расширение LanguageTool интегрируется в меню сервис и имеет локализацию (перевод) пунктов в меню по крайней иере для 10 языков
При работе с OOo c английским интерфейсом всё работает отлично,
При переключении на русский в меню сервис отображается серым цветом слово  LanguageTool
Меню недоступно.
Это баг или особенность локализации новых версий ООО?

[Рыбка Рио]

В Addons.xcu нужно писать не en-US, а en, не ru-RU, а ru и т.д.

[Рыбка Рио]

http://www.openoffice.org/issues/show_bug.cgi?id=114078

[Yakov]

Спасибо!

[Yakov]

http://sourceforge.net/mailarchive/forum.php?thread_name=E1Onlr0-0004O1-00.yakovr_st-mail-ru%40f287.mail.ru&forum_name=languagetool-devel

[Yakov]

Всё-таки Addons.xcu придётся править  = Для OOo3.3.0 нужна будет новая версия LanguageTool и, возможно, других расширений.
Ответ sb в issue:

When looking at the Addons.xcu in LanguageTool-1.0.0.oxt, all the used xml:lang
attributes are of the two-piece form "<language>-<country>" ("en-US", "pl-PL",
"es-ES", etc.).

The configmgr code that shall select the best value for the given locale is
based on the lookup matching rules of RFC 4647 (see
<http://hg.services.openoffice.org/DEV300/file/87f4911ea629/configmgr/source/childaccess.cxx#l279>).
 If the given locale is "foo-bar", and there is a xml:lang="foo-bar" among the
configuration values, it will return that value.  If the given locale is "foo",
and there is only a xml:lang="foo-bar" among the configuration values (and no
xml:lang="foo"), it will fall back to the default ("en-US") value.  This is in
accordance with RFC 4647: "For example, if the language range is 'de-ch', a
lookup operation can produce content with the tags 'de' or 'de-CH' but never
content with the tag 'de-CH-1996'."

Now, the important thing is what locale string is passed from the OOo code to
configmgr (a two-piece "foo-bar" string or a one-piece "foo" string).  This
depends on the environment in which OOo is run.  If it is run within a US
environment, the locale string is "en-US".  If it is run in a Polish
environment, the locale string is "pl", not "pl-PL".

That explains why, when run in a Polish environment, apparently wrong values are
taken from the given Addons.xcu -- "pl" does not match "pl-PL", so the fallback
("en-US") value is used.

To fix this, you should adapt the extension's Addons.xcu to contain xml:lang
locale strings that are as short as possible (after all, the Polish value you
provide is probably good for all Polish-language environments, not just for a
Plish-language-in-Poland environment).  Also, you could look at the locale
strings actually used for localized content within OOo itself, see the list of
directories at
<http://hg.services.openoffice.org/DEV300/file/87f4911ea629/l10n/source>.

[Yakov]

Исправлено в CVS LanguageTool
http://languagetool.cvs.sourceforge.net/viewvc/languagetool/JLanguageTool/openoffice/Addons.xcu?revision=1.27

[Yakov]

В Addons.xcu нужно писать не en-US, а en, не ru-RU, а ru и т.д.

На самом деле ru, pl, sl, но en-US!
Обещают исправить на en в 3.4
http://www.openoffice.org/issues/show_bug.cgi?id=114155

Upd:
Непонятно, как правильно должна быть белорусская локаль: be или be-BY?

[Рыбка Рио]

Лучше писать, наверное, be, но можно и be-BY (т.к. тут оно есть http://hg.services.openoffice.org/DEV300/file/87f4911ea629/l10n/source).

Тоже самое, оказывается, и с en. Можно писать en, можно en-US. Если перевод отсутствует, то вначале OOo ищет en-US, если не находит то первую запись. В вашем случае первая запись - значение для en (http://languagetool.cvs.sourceforge.net/viewvc/languagetool/JLanguageTool/openoffice/Addons.xcu?revision=1.27), так что LanguageTool тема http://www.openoffice.org/issues/show_bug.cgi?id=114155 не каcается.

[Рыбка Рио]

Если вы, к примеру, не хотите, что английский перевод был переводом по умолчанию, то можно на первое место поставить  другой язык ( к примеру, fr), писать при этом нужно en, а не en-US, т.к. присутствие en-US сделает его языком по умолчанию. После исправления issue 114155 , значение en так же будет восприниматься как язык по умолчанию. Но в LanguageTool en и так стоит на первом месте, поэтому там всё равно как вы напишете en или en-US, но самое простое, если вы будете следовать правилу, которое написали sb: "you should adapt the extension's Addons.xcu to contain xml:lang locale strings that are as short as possible". Понимаете? Т.е. пишите en, be и т.д. - и не ошибетесь. Хотя для be можно писать и be-BY (но опять же, если напишете be - то не ошибетесь).

[Рыбка Рио]

Хотя нет, извините, я ошибаюсь насчёт того, что первый в списке - язык по умолчанию (тогда вправду, лучше пока писать en-US). sb ведь написали, что это должен быть первый язык в configmgr, а не в xcu.

the first item within the configmgr implementation, which typically is not the textually first one in the .xcu file, but rather the lexicographically smallest one, like "be".

[Рыбка Рио]

Исправили это в 3.3 (en - язык по умолчанию, как и en-US)
(Issue 115386)