Issue 113873

Summary: Russian dictionary for integration
Product: General Reporter: fyva <menenem>
Component: spell checkingAssignee: Martin Hollmichel <nesshof>
Status: RESOLVED FIXED QA Contact: issues@lingucomponent <issues>
Severity: Trivial    
Priority: P3 CC: issues, issues, mr_smyle, rail_ooo, thomas.lange
Version: 3.3.0 or older (OOo)   
Target Milestone: ---   
Hardware: Unknown   
OS: All   
URL: http://extensions.services.openoffice.org/project/dict_ru_RU
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
the license none

Description fyva 2010-08-13 21:04:59 UTC
Consider this spell checking dictionary for integration.
http://extensions.services.openoffice.org/project/dict_ru_RU

If the dictionary is suitable for integration, then this spell dictionary can be
merged with the already integrated russian hyphenation and thesaurus dictionaries.

The license is attached below.
Comment 1 fyva 2010-08-13 21:05:58 UTC
Created attachment 71100 [details]
the license
Comment 2 thomas.lange 2010-08-14 04:54:34 UTC
tl->mh: I checked with the Russian dictionary extension we already have in our
source code (dictionaries/ru_RU), the one we are using with Russian builds. The
extension listed here is a different one. 

tl->fyva: Have a look at
http://hg.services.openoffice.org/OOO330/file/03cf80e29979/dictionaries. There
you can see all the dictionaries that are already part of our source code. If
you like any of them to be available for Ukrainian Office builds (NOT language
packs, that's a different matter) please list the locales of the dictionaries
you like to have added by default to an Ukrainian build. When the extension
above is approved I will add them as well to the list of extension to be packed.
Thanks in advance!
Comment 3 thomas.lange 2010-08-14 05:24:39 UTC
Having us merge the extension you listed (lets call it  B) with parts of the
other one from our source code (lets call it A) is not a really good idea. The
reason for this is that:

By merging B with parts of A we will technically create a new extension (lets
call it C to which we also have to assign an identifier. Thus later on one of
the following will happen:

1) I we use the a new identifier for C, then there will be no update
notifications for that one even if A or B will get updated in the repository.
In that case the only way to get a new version of the extension will be to
install a newer Office with a newer version of that extension. 

2) If we use the identifier of either A or B, then upon update of those the
installed extension C will be removed and replaced by A or B. Thus the user will
either loose the spell check dictionary from B or the thesaurus and hyphenation
file from A. 

Also A and C can not be installed together since then we will have conflicting
spell check dictionaries and thus at best will get mangled results from the
spell checker.

tl->fyva: Thus correct solutions would be
- decide on a single extension (A or B)
- have the author of A split up his extension in two (A1: spell check dictionary
and A2: thesaurus and hyphenation). The we can include both of the extensions B
and A2 for Ukrainian (and A1 and A2 for Russian), and then everything should be fine
- you need to get permission of the author of A to break his extension, extract
thesaurus and hyphenation and the create a new extension C2 (with new
identifier) from those on your own. We could then integrate that and if you or
anyone else later on provide updates for that extension, then the user will get
a proper update as well.
- have me implement 1) from above and go with the implied drawbacks

Please make your choice. 

tl->mh: What is your opinion to solution 1). Would that be acceptable, or should
we refrain from doing this?
Comment 4 fyva 2010-08-14 08:00:00 UTC
There already exists a combination of the 2 extensions with the new identifier
(with a bit different version of the spell checking dictionary - a few words
added and the words are organized alphabetically - see changelog inside):
http://extensions.services.openoffice.org/project/dictru
(it was packaged by me from the 2 extensions 9 months ago)

The author of the 2 extensions (one already integrated and the other is
discussed in this issue) is our lead - rail. (Adding them to CC)
Originally, my package was wrong licenced, and we discussed this with rail. But
now I fixed the licenses and edited description at the extensions site.

BTW, is it possible to have the Ukrainian dictionary (not yet approved, see
issue 113874) included in the Russian build? For now, the Russian build contains
these dictionaries: English, German and Russian. Is it possible to add Ukrainian
there in exchange for German or as a fourth dictionary?
Comment 5 fyva 2010-08-14 09:30:39 UTC
fyva->tl: As for the Ukrainian Office builds, IMHO, the locales should be: uk_UA
(it is missing in the list so far, but if the dictionary in the issue 113874 is
approved it should appear), ru_RU (if the dictionary in this issue is approved)
, and en (English). If some of these locales are missing, pl_PL and de_DE can be
used instead. (pl_PL (Poland) and de_DE (German) fully support spelling,
hyphenation and thesaurus.)
Comment 6 fyva 2010-08-14 11:14:35 UTC
In addition, mr_smyle suggested to use ro (Romanian) instead of de_DE, because
Ukraine doesn't have common borders with Germany and German language is used
very rarely.
Comment 7 Pedro Giffuni 2011-11-30 01:51:47 UTC
Committed as Revision 1208206.

We have not yet decided how the dictionary distribution
on Apache OpenOffice will be, and it looks like they will
be temporarily removed from the tree but the license in
this dictionary is much better than the one of the previous
one. So I am making sure we will use it when we "resurrect"
them.

Thank you for your contribution!