You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Andre Fischer <af...@a-w-f.de> on 2012/03/22 10:25:45 UTC
[RELEASE] Dictionary extensions
Hi all,
I need your help.
We are now able to include extensions -- dictionaries and others -- into
installation sets, depending on the language(s) for which an
installation set is built.
All that is needed is a list of extensions that are to be bundled for
each language. At the moment this list only contains entries for
english and german.
If you want to have dictionaries included for other languages then you
can do that in one of several ways:
- Edit [1] in the confluence wiki and then tell me about it so that I
can update the main/extensions.lst file. The important part is to
provide working URLs int the "Upstream link" comment. The URLs may,
however, contain redirections (like the ones from
http://extensions.services.openoffice.org/en/dictionaries).
Note that you can edit this wiki only when you are a commiter.
- Reply to this message on ooo-dev or personally to me. Again, it is
important that I get working URLs.
- Edit main/extensions.lst yourself. I tried to document the format in
[2] but it should be pretty clear just by looking at extensions.lst.
Best regards,
Andre
[1]
https://cwiki.apache.org/confluence/display/OOOUSERS/Bundled+Writing+Aids
[2]
http://wiki.services.openoffice.org/wiki/Build_Bootstrapping#extensions.lst
Re: [RELEASE] Dictionary extensions
Posted by xia zhao <li...@gmail.com>.
Andre,
One question here. If we include extension, for example, dictionaries in
installation sets, that will be no specific related dictionary extension
provided on extension page?
Why I ask this question is I found Simplified Chinese full package has been
provided on dev snap shot but no Simplified Chinese dictionary package on
extension page.
Lily
2012/3/22 Andre Fischer <af...@a-w-f.de>
> Hi all,
>
> I need your help.
>
> We are now able to include extensions -- dictionaries and others -- into
> installation sets, depending on the language(s) for which an installation
> set is built.
>
> All that is needed is a list of extensions that are to be bundled for each
> language. At the moment this list only contains entries for english and
> german.
>
> If you want to have dictionaries included for other languages then you can
> do that in one of several ways:
>
> - Edit [1] in the confluence wiki and then tell me about it so that I can
> update the main/extensions.lst file. The important part is to provide
> working URLs int the "Upstream link" comment. The URLs may, however,
> contain redirections (like the ones from http://extensions.services.**
> openoffice.org/en/dictionaries<http://extensions.services.openoffice.org/en/dictionaries>
> **).
> Note that you can edit this wiki only when you are a commiter.
>
> - Reply to this message on ooo-dev or personally to me. Again, it is
> important that I get working URLs.
>
> - Edit main/extensions.lst yourself. I tried to document the format in
> [2] but it should be pretty clear just by looking at extensions.lst.
>
>
> Best regards,
> Andre
>
>
> [1] https://cwiki.apache.org/**confluence/display/OOOUSERS/**
> Bundled+Writing+Aids<https://cwiki.apache.org/confluence/display/OOOUSERS/Bundled+Writing+Aids>
> [2] http://wiki.services.**openoffice.org/wiki/Build_**
> Bootstrapping#extensions.lst<http://wiki.services.openoffice.org/wiki/Build_Bootstrapping#extensions.lst>
>
Re: [RELEASE] Dictionary extensions
Posted by Pedro Giffuni <pf...@apache.org>.
On 03/29/12 09:45, Yakov Reztsov wrote:
> ...
> Can be it is necessary to add the file th_ru_RU_v2.idx
> to SVN (http://svn.apache.org/viewvc/incubator/ooo/trunk/main/dictionaries/ru_RU/?pathrev=1209016)?
>
That branch doesn't exist anymore on our Apache SVN. I
am of the opinion that we should restore it outside, probably
in apache-extras.org and generate all dictionaries there.
FWIW, The LibreOffice guys have the dictionaries in an
independent GIT repository.
cheers,
Pedro.
Re[2]: [RELEASE] Dictionary extensions
Posted by Yakov Reztsov <ya...@mail.ru>.
Tue, 27 Mar 2012 15:08:58 -0700 (PDT) от Pedro Giffuni:
>
>
> --- Mar 27/3/12, Andrea Pescetti <pe...@apache.org> ha scritto:
> ...
> > > I downloaded the source from SVN.
> > > But did not find the file th_ru_RU_v2.idx
> > > Maybe it has to be generated during the build process?
> > > Checked that in the dictionary for the German
> > equivalent file is present (this thesaurus index file).
> > > Generated with the help of his MyThes and assembled a
> > complete test version of the dictionary.
> >
> > Index files could be generated at build time, but
> > OpenOffice.org historically did not do it, preferring to use
> > pre-built files. And now that included dictionaries must be
> > packaged as verbatim extensions, we will surely need to
> > package the index file in the extensions rather than
> > generating it at build time.
> >
>
> I think I pointed to the right russian dictionary in the
> Wiki and I am adding some few extension that were
> requested in Bugzilla.
>
Can be it is necessary to add the file th_ru_RU_v2.idx
to SVN (http://svn.apache.org/viewvc/incubator/ooo/trunk/main/dictionaries/ru_RU/?pathrev=1209016)?
--
Yakov Reztsov
Re: [RELEASE] Dictionary extensions
Posted by Hagar Delest <ha...@laposte.net>.
> On 3/29/12 11:13 AM, Rory O'Farrell wrote:
>> It is worth noting that a frequent
>> question from users is how to remove unwanted
>> preinstalled dictionaries. In a future release perhaps a
>> modification of the install process might allow selection of
>> dictionaries at install time. I suspect, but do not know for
>> certain, that in some cases such users wish to economise on
>> memory, be it storage or RAM, used by the program when installed
>> on older computers.
>>
> this is valuable feedback and we should take care of this in the future. As always and everywhere we have a lot of areas where we can improve things.
>
> That means that we exactly need the feedback from our users (home as well as enterprise users). In the end the tasks they want to achieve are very similar for all. Our focus for the future should be to make
> things as easy as possible for our users.
>
> Juergen
In the same area, it's rather strange that the whole list of languages is available in the drop-down lists that are easily accessible to users (in the Font properties tab for example) whereas only installed dics are listed in Tools>Options>Language and Settings>Writing Aids>Modules.
The long list is either confusing (are all these languages installed?) or not convenient (I've to move along the whole list to find the correct language). It would be more logical to have the opposite:
- short list (only installed dics) in the "common" settings
- long list (with the check mark for installed languages) in the advanced options (Tools>Options>...)
In the forum, very often, users don't make the difference at first between a language with a check mark (installed) and without in the list.
Just my 2 ct, sorry to be OT here. Can make a bug report if needed.
Hagar
Re: [RELEASE] Dictionary extensions
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 3/29/12 11:13 AM, Rory O'Farrell wrote:
> On Thu, 29 Mar 2012 10:23:36 +0200
> Andre Fischer<af...@a-w-f.de> wrote:
>
>> On 29.03.2012 10:02, Gianluca Turconi wrote:
>>> In data 28 marzo 2012 alle ore 18:06:33, Andre Fischer
>>> <af...@a-w-f.de> ha scritto:
>>>
>>>> Please note that at the moment only two languages will have
>>>> more than their "native" dictionary bundled: nl and ru.
>>>> Please speak up if you want more dictionaries for other
>>>> languages as well.
>>>
>>> I've just sent a mail about this topic to the Italian user ML.
>>>
>>> I'll give here any feedback from the users, if any will be
>>> provided.
>>>
>>> Personally, I think they should surely be included:
>>>
>>> Italian
>>> English (US or GB)
>>
>> Please keep in mind that we currently have no en_GB.
>>
>>>
>>> However, these dictionaries
>>>
>>> French
>>> German
>>> Spanish (Espana)
>>>
>>> may be useful too to many Italian users, in my opinion.
>>
>> OK, I will wait.
>>
>>>
>>> Is there a near deadline for "speaking up"? :-)
>>
>> The deadline is our release.
>> But the sooner the better.
>>
>>>
>>> Regards,
>>
>
> It is worth noting that a frequent
> question from users is how to remove unwanted
> preinstalled dictionaries. In a future release perhaps a
> modification of the install process might allow selection of
> dictionaries at install time. I suspect, but do not know for
> certain, that in some cases such users wish to economise on
> memory, be it storage or RAM, used by the program when installed
> on older computers.
>
this is valuable feedback and we should take care of this in the future.
As always and everywhere we have a lot of areas where we can improve
things.
That means that we exactly need the feedback from our users (home as
well as enterprise users). In the end the tasks they want to achieve are
very similar for all. Our focus for the future should be to make
things as easy as possible for our users.
Juergen
Re: [RELEASE] Dictionary extensions
Posted by Rory O'Farrell <of...@iol.ie>.
On Thu, 29 Mar 2012 10:23:36 +0200
Andre Fischer <af...@a-w-f.de> wrote:
> On 29.03.2012 10:02, Gianluca Turconi wrote:
> > In data 28 marzo 2012 alle ore 18:06:33, Andre Fischer
> > <af...@a-w-f.de> ha scritto:
> >
> >> Please note that at the moment only two languages will have
> >> more than their "native" dictionary bundled: nl and ru.
> >> Please speak up if you want more dictionaries for other
> >> languages as well.
> >
> > I've just sent a mail about this topic to the Italian user ML.
> >
> > I'll give here any feedback from the users, if any will be
> > provided.
> >
> > Personally, I think they should surely be included:
> >
> > Italian
> > English (US or GB)
>
> Please keep in mind that we currently have no en_GB.
>
> >
> > However, these dictionaries
> >
> > French
> > German
> > Spanish (Espana)
> >
> > may be useful too to many Italian users, in my opinion.
>
> OK, I will wait.
>
> >
> > Is there a near deadline for "speaking up"? :-)
>
> The deadline is our release.
> But the sooner the better.
>
> >
> > Regards,
>
It is worth noting that a frequent
question from users is how to remove unwanted
preinstalled dictionaries. In a future release perhaps a
modification of the install process might allow selection of
dictionaries at install time. I suspect, but do not know for
certain, that in some cases such users wish to economise on
memory, be it storage or RAM, used by the program when installed
on older computers.
--
Rory O'Farrell <of...@iol.ie>
Re: [RELEASE] Dictionary extensions
Posted by Andre Fischer <af...@a-w-f.de>.
On 29.03.2012 10:02, Gianluca Turconi wrote:
> In data 28 marzo 2012 alle ore 18:06:33, Andre Fischer <af...@a-w-f.de> ha
> scritto:
>
>> Please note that at the moment only two languages will have more than
>> their "native" dictionary bundled: nl and ru.
>> Please speak up if you want more dictionaries for other languages as
>> well.
>
> I've just sent a mail about this topic to the Italian user ML.
>
> I'll give here any feedback from the users, if any will be provided.
>
> Personally, I think they should surely be included:
>
> Italian
> English (US or GB)
Please keep in mind that we currently have no en_GB.
>
> However, these dictionaries
>
> French
> German
> Spanish (Espana)
>
> may be useful too to many Italian users, in my opinion.
OK, I will wait.
>
> Is there a near deadline for "speaking up"? :-)
The deadline is our release.
But the sooner the better.
>
> Regards,
Re: [RELEASE] Dictionary extensions
Posted by Gianluca Turconi <gt...@letturefantastiche.com>.
In data 28 marzo 2012 alle ore 18:06:33, Andre Fischer <af...@a-w-f.de> ha
scritto:
> Please note that at the moment only two languages will have more than
> their "native" dictionary bundled: nl and ru.
> Please speak up if you want more dictionaries for other languages as
> well.
I've just sent a mail about this topic to the Italian user ML.
I'll give here any feedback from the users, if any will be provided.
Personally, I think they should surely be included:
Italian
English (US or GB)
However, these dictionaries
French
German
Spanish (Espana)
may be useful too to many Italian users, in my opinion.
Is there a near deadline for "speaking up"? :-)
Regards,
--
Gianluca Turconi
Lettura gratuita o acquisto di libri e racconti di fantascienza,
fantasy, horror, noir, narrativa fantastica e tradizionale:
http://www.letturefantastiche.com/
Re: [RELEASE] Dictionary extensions
Posted by Andre Fischer <af...@a-w-f.de>.
On 28.03.2012 00:08, Pedro Giffuni wrote:
>
>
> --- Mar 27/3/12, Andrea Pescetti<pe...@apache.org> ha scritto:
> ...
>>> I downloaded the source from SVN.
>>> But did not find the file th_ru_RU_v2.idx
>>> Maybe it has to be generated during the build process?
>>> Checked that in the dictionary for the German
>> equivalent file is present (this thesaurus index file).
>>> Generated with the help of his MyThes and assembled a
>> complete test version of the dictionary.
>>
>> Index files could be generated at build time, but
>> OpenOffice.org historically did not do it, preferring to use
>> pre-built files. And now that included dictionaries must be
>> packaged as verbatim extensions, we will surely need to
>> package the index file in the extensions rather than
>> generating it at build time.
>>
>
> I think I pointed to the right russian dictionary in the
> Wiki and I am adding some few extension that were
> requested in Bugzilla.
>
> Croatian is a special case, they relicensed their dict to
> ALv2 but the one in the extensions site:
>
> http://extensions.services.openoffice.org/en/search/node/croatian
>
> doesn't seem to be updated. We need someone that will
> regenerate it (it does include idx).
I have updated main/extensions.lst accordingly.
Please note that at the moment only two languages will have more than
their "native" dictionary bundled: nl and ru.
Please speak up if you want more dictionaries for other languages as well.
I also updated some language names in the "Language" column on the wiki
page to values that are understood by our build environment (especially
the --with-lang configure switch): removed the country parts, eg fr_FR
became fr.
Updated the download link for Norwegian due to problems with the redirect.
Finally, I added a new switch to configure. By saying
--disable-bundled-dictionaries you can now, well, disable the bundling
of dictionary extensions. More importantly it detects whether hunspell
is available. If not the dictionaries are not bundled because the would
not work anyway.
-Andre
>
> Cheers,
>
> Pedro.
Re: [RELEASE] Dictionary extensions
Posted by Pedro Giffuni <pf...@apache.org>.
--- Mar 27/3/12, Andrea Pescetti <pe...@apache.org> ha scritto:
...
> > I downloaded the source from SVN.
> > But did not find the file th_ru_RU_v2.idx
> > Maybe it has to be generated during the build process?
> > Checked that in the dictionary for the German
> equivalent file is present (this thesaurus index file).
> > Generated with the help of his MyThes and assembled a
> complete test version of the dictionary.
>
> Index files could be generated at build time, but
> OpenOffice.org historically did not do it, preferring to use
> pre-built files. And now that included dictionaries must be
> packaged as verbatim extensions, we will surely need to
> package the index file in the extensions rather than
> generating it at build time.
>
I think I pointed to the right russian dictionary in the
Wiki and I am adding some few extension that were
requested in Bugzilla.
Croatian is a special case, they relicensed their dict to
ALv2 but the one in the extensions site:
http://extensions.services.openoffice.org/en/search/node/croatian
doesn't seem to be updated. We need someone that will
regenerate it (it does include idx).
Cheers,
Pedro.
Re: [RELEASE] Dictionary extensions
Posted by Andrea Pescetti <pe...@apache.org>.
Yakov Reztsov wrote:
> I decided to check dictionary from Apache SVN. ( http://svn.apache.org/viewvc/incubator/ooo/trunk/main/dictionaries/ru_RU/?pathrev=1209016)
> I downloaded the source from SVN.
> But did not find the file th_ru_RU_v2.idx
> Maybe it has to be generated during the build process?
> Checked that in the dictionary for the German equivalent file is present (this thesaurus index file).
> Generated with the help of his MyThes and assembled a complete test version of the dictionary.
Index files could be generated at build time, but OpenOffice.org
historically did not do it, preferring to use pre-built files. And now
that included dictionaries must be packaged as verbatim extensions, we
will surely need to package the index file in the extensions rather than
generating it at build time.
Regards,
Andrea.
R: Re[3]: [RELEASE] Dictionary extensions
Posted by Pedro Giffuni <pf...@apache.org>.
Hmm...
According to the BZ issue, this extension should be the appropriate one:
http://extensions.services.openoffice.org/project/dictru
So I just added it to the Wiki.
cheers,
Pedro.
--- Mar 27/3/12, Yakov Reztsov <ya...@mail.ru> ha scritto:
>
> Hi Andre,
>
> Tue, 27 Mar 2012 22:11:06 +0400 от Yakov Reztsov :
> > Hi Andre,
> >
> >
> > Tue, 27 Mar 2012 21:38:52 +0400 от Torokhov Sergey:
> > > On Tuesday 27 of March 2012 11:32:25 Andre Fischer
> wrote:
> > > > Hi Yakov,
> > > >
> > > > thanks for your input. I still need to
> know which Russian dictionary to
> > > > include. On
> > > >
> > > > http://extensions.services.openoffice.org/en/dictionaries
> > > >
> > > > there are listed 8 different extensions.
> > > >
> > > > -Andre
> > > >
> > > > On 26.03.2012 19:15, Yakov Reztsov wrote:
> > > > > Hi Andre,
> > > > >
> > > > > I think in a Russian AOO the following
> languages should be bundled:
> > > > > Russian (ru_RU)
> > > > > http://svn.apache.org/viewvc/incubator/ooo/trunk/main/dictionaries/ru_RU
> > > > > /?pathrev=1209016 English (en_US)
> > > > > German (de_DE)
> > >
> > > Hi Andre,
> > >
> > > I observe, and Yakov confirmed it for me early,
> that proposed set
> > > http://svn.apache.org/viewvc/incubator/ooo/trunk/main/dictionaries/ru_RU/?pathrev=1209016
> > >
> > > already includes the following russian
> spellchecker dictionary:
> > > http://extensions.services.openoffice.org/en/project/dict_ru_RU_hyph
> > >
> > > as files "ru_RU.dic" and "ru_RU.aff".
> > >
> > >
> >
> > In dictionary
> > http://extensions.services.openoffice.org/en/project/dict_ru_RU_hyph
> > included only spellcheck dictionary and
> hyphenation.
> > Thesaurus is not included in this version.
> > In http://svn.apache.org/viewvc/incubator/ooo/trunk/main/dictionaries/ru_RU/?pathrev=1209016
> > is full extension with spellcheck, hyphenation
> and thesaurus dictionary.
> >
>
> I decided to check dictionary from Apache SVN. (
> http://svn.apache.org/viewvc/incubator/ooo/trunk/main/dictionaries/ru_RU/?pathrev=1209016)
> I downloaded the source from SVN.
> But did not find the file th_ru_RU_v2.idx
> Maybe it has to be generated during the build process?
> Checked that in the dictionary for the German equivalent
> file is present (this thesaurus index file).
> Generated with the help of his MyThes and assembled a
> complete test version of the dictionary.
>
> I am build Russian test dictionary extension based on
> SVN:
> http://forumooo.ru/index.php?action=dlattach;topic=2562.0;attach=3925
>
> --
> Yakov Reztsov
>
Re[3]: [RELEASE] Dictionary extensions
Posted by Yakov Reztsov <ya...@mail.ru>.
Hi Andre,
Tue, 27 Mar 2012 22:11:06 +0400 от Yakov Reztsov :
> Hi Andre,
>
>
> Tue, 27 Mar 2012 21:38:52 +0400 от Torokhov Sergey:
> > On Tuesday 27 of March 2012 11:32:25 Andre Fischer wrote:
> > > Hi Yakov,
> > >
> > > thanks for your input. I still need to know which Russian dictionary to
> > > include. On
> > >
> > > http://extensions.services.openoffice.org/en/dictionaries
> > >
> > > there are listed 8 different extensions.
> > >
> > > -Andre
> > >
> > > On 26.03.2012 19:15, Yakov Reztsov wrote:
> > > > Hi Andre,
> > > >
> > > > I think in a Russian AOO the following languages should be bundled:
> > > > Russian (ru_RU)
> > > > http://svn.apache.org/viewvc/incubator/ooo/trunk/main/dictionaries/ru_RU
> > > > /?pathrev=1209016 English (en_US)
> > > > German (de_DE)
> >
> > Hi Andre,
> >
> > I observe, and Yakov confirmed it for me early, that proposed set
> > http://svn.apache.org/viewvc/incubator/ooo/trunk/main/dictionaries/ru_RU/?pathrev=1209016
> >
> > already includes the following russian spellchecker dictionary:
> > http://extensions.services.openoffice.org/en/project/dict_ru_RU_hyph
> >
> > as files "ru_RU.dic" and "ru_RU.aff".
> >
> >
>
> In dictionary
> http://extensions.services.openoffice.org/en/project/dict_ru_RU_hyph
> included only spellcheck dictionary and hyphenation.
> Thesaurus is not included in this version.
> In http://svn.apache.org/viewvc/incubator/ooo/trunk/main/dictionaries/ru_RU/?pathrev=1209016
> is full extension with spellcheck, hyphenation and thesaurus dictionary.
>
I decided to check dictionary from Apache SVN. ( http://svn.apache.org/viewvc/incubator/ooo/trunk/main/dictionaries/ru_RU/?pathrev=1209016)
I downloaded the source from SVN.
But did not find the file th_ru_RU_v2.idx
Maybe it has to be generated during the build process?
Checked that in the dictionary for the German equivalent file is present (this thesaurus index file).
Generated with the help of his MyThes and assembled a complete test version of the dictionary.
I am build Russian test dictionary extension based on SVN:
http://forumooo.ru/index.php?action=dlattach;topic=2562.0;attach=3925
--
Yakov Reztsov
Re[2]: [RELEASE] Dictionary extensions
Posted by Yakov Reztsov <ya...@mail.ru>.
Hi Andre,
Tue, 27 Mar 2012 21:38:52 +0400 от Torokhov Sergey:
> On Tuesday 27 of March 2012 11:32:25 Andre Fischer wrote:
> > Hi Yakov,
> >
> > thanks for your input. I still need to know which Russian dictionary to
> > include. On
> >
> > http://extensions.services.openoffice.org/en/dictionaries
> >
> > there are listed 8 different extensions.
> >
> > -Andre
> >
> > On 26.03.2012 19:15, Yakov Reztsov wrote:
> > > Hi Andre,
> > >
> > > I think in a Russian AOO the following languages should be bundled:
> > > Russian (ru_RU)
> > > http://svn.apache.org/viewvc/incubator/ooo/trunk/main/dictionaries/ru_RU
> > > /?pathrev=1209016 English (en_US)
> > > German (de_DE)
>
> Hi Andre,
>
> I observe, and Yakov confirmed it for me early, that proposed set
> http://svn.apache.org/viewvc/incubator/ooo/trunk/main/dictionaries/ru_RU/?pathrev=1209016
>
> already includes the following russian spellchecker dictionary:
> http://extensions.services.openoffice.org/en/project/dict_ru_RU_hyph
>
> as files "ru_RU.dic" and "ru_RU.aff".
>
>
In dictionary
http://extensions.services.openoffice.org/en/project/dict_ru_RU_hyph
included only spellcheck dictionary and hyphenation.
Thesaurus is not included in this version.
In http://svn.apache.org/viewvc/incubator/ooo/trunk/main/dictionaries/ru_RU/?pathrev=1209016
is full extension with spellcheck, hyphenation and thesaurus dictionary.
--
Yakov Reztsov
Re: [RELEASE] Dictionary extensions
Posted by Torokhov Sergey <to...@mail.ru>.
On Tuesday 27 of March 2012 11:32:25 Andre Fischer wrote:
> Hi Yakov,
>
> thanks for your input. I still need to know which Russian dictionary to
> include. On
>
> http://extensions.services.openoffice.org/en/dictionaries
>
> there are listed 8 different extensions.
>
> -Andre
>
> On 26.03.2012 19:15, Yakov Reztsov wrote:
> > Hi Andre,
> >
> > I think in a Russian AOO the following languages should be bundled:
> > Russian (ru_RU)
> > http://svn.apache.org/viewvc/incubator/ooo/trunk/main/dictionaries/ru_RU
> > /?pathrev=1209016 English (en_US)
> > German (de_DE)
Hi Andre,
I observe, and Yakov confirmed it for me early, that proposed set
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/dictionaries/ru_RU/?pathrev=1209016
already includes the following russian spellchecker dictionary:
http://extensions.services.openoffice.org/en/project/dict_ru_RU_hyph
as files "ru_RU.dic" and "ru_RU.aff".
--
Regards
Re: [RELEASE] Dictionary extensions
Posted by Andre Fischer <af...@a-w-f.de>.
Hi Yakov,
thanks for your input. I still need to know which Russian dictionary to
include. On
http://extensions.services.openoffice.org/en/dictionaries
there are listed 8 different extensions.
-Andre
On 26.03.2012 19:15, Yakov Reztsov wrote:
> Hi Andre,
>
> I think in a Russian AOO the following languages should be bundled:
> Russian (ru_RU) http://svn.apache.org/viewvc/incubator/ooo/trunk/main/dictionaries/ru_RU/?pathrev=1209016
> English (en_US)
> German (de_DE)
>
>
>
> Best regards
> Yakov Reztsov
>
> Op 22-3-2012 10:25, Andre Fischer schreef:
>> Hi all,
>>
>> I need your help.
>>
>> We are now able to include extensions -- dictionaries and others -- into
>> installation sets, depending on the language(s) for which an
>> installation set is built.
>>
>> All that is needed is a list of extensions that are to be bundled for
>> each language. At the moment this list only contains entries for english
>> and german.
>>
>> If you want to have dictionaries included for other languages then you
>> can do that in one of several ways:
>>
>> - Edit [1] in the confluence wiki and then tell me about it so that I
>> can update the main/extensions.lst file. The important part is to
>> provide working URLs int the "Upstream link" comment. The URLs may,
>> however, contain redirections (like the ones from
>> http://extensions.services.openoffice.org/en/dictionaries).
>> Note that you can edit this wiki only when you are a commiter.
>>
>> - Reply to this message on ooo-dev or personally to me. Again, it is
>> important that I get working URLs.
>>
>> - Edit main/extensions.lst yourself. I tried to document the format in
>> [2] but it should be pretty clear just by looking at extensions.lst.
>>
>>
>> Best regards,
>> Andre
>>
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/OOOUSERS/Bundled+Writing+Aids
>> [2]
>> http://wiki.services.openoffice.org/wiki/Build_Bootstrapping#extensions.lst
>>
Re: [RELEASE] Dictionary extensions
Posted by Yakov Reztsov <ya...@mail.ru>.
Hi Andre,
I think in a Russian AOO the following languages should be bundled:
Russian (ru_RU) http://svn.apache.org/viewvc/incubator/ooo/trunk/main/dictionaries/ru_RU/?pathrev=1209016
English (en_US)
German (de_DE)
Best regards
Yakov Reztsov
Op 22-3-2012 10:25, Andre Fischer schreef:
> Hi all,
>
> I need your help.
>
> We are now able to include extensions -- dictionaries and others -- into
> installation sets, depending on the language(s) for which an
> installation set is built.
>
> All that is needed is a list of extensions that are to be bundled for
> each language. At the moment this list only contains entries for english
> and german.
>
> If you want to have dictionaries included for other languages then you
> can do that in one of several ways:
>
> - Edit [1] in the confluence wiki and then tell me about it so that I
> can update the main/extensions.lst file. The important part is to
> provide working URLs int the "Upstream link" comment. The URLs may,
> however, contain redirections (like the ones from
> http://extensions.services.openoffice.org/en/dictionaries).
> Note that you can edit this wiki only when you are a commiter.
>
> - Reply to this message on ooo-dev or personally to me. Again, it is
> important that I get working URLs.
>
> - Edit main/extensions.lst yourself. I tried to document the format in
> [2] but it should be pretty clear just by looking at extensions.lst.
>
>
> Best regards,
> Andre
>
>
> [1]
> https://cwiki.apache.org/confluence/display/OOOUSERS/Bundled+Writing+Aids
> [2]
> http://wiki.services.openoffice.org/wiki/Build_Bootstrapping#extensions.lst
>
Re: [RELEASE] Dictionary extensions
Posted by Andre Fischer <af...@a-w-f.de>.
On 26.03.2012 20:59, Simon Brouwer wrote:
> Hi Andre,
>
> There is one at http://en-gb.pyxidium.co.uk/dictionary/OOo.php but the
> zip just contains the .dic and .aff files; it is not in .oxt format.
> The readme states the files are derived from lgpl sources and therefore
> lgpl as well.
>
> If nothing better is found, I could have a go at wrapping a .oxt around it.
If you provide the extension then I will add it.
-Andre
>
> Best regards,
> Simon
>
>
>
> Op 26-3-2012 11:46, Andre Fischer schreef:
>> On 23.03.2012 22:15, Simon Brouwer wrote:
>>> Hi Andre,
>>>
>>> I think in a Dutch AOO the following languages should be bundled:
>>> Dutch (nl_NL)
>>> English (en_GB and en_US)
>>> French (fr_FR)
>>> German (de_DE)
>>
>> After reading your mail again, I suppose that you want dictionaries
>> nl_NL, en_GB, en_US, fr_FR, and de_DE added for dutch.
>>
>> I can add all of these except en_GB. The link on [1] lead to dead links
>> (on an ftp server that is not online anymore.)
>>
>> I will update the Wiki and main/extensions.lst.
>>
>> If anyone finds a working en_GB dictionary, please speak up.
>>
>> -Andre
>>
>>>
>>> I have added URLs of these in [1] if missing.
>>>
>>> Best regards
>>> Simon.
>>>
>>> Op 22-3-2012 10:25, Andre Fischer schreef:
>>>> Hi all,
>>>>
>>>> I need your help.
>>>>
>>>> We are now able to include extensions -- dictionaries and others --
>>>> into
>>>> installation sets, depending on the language(s) for which an
>>>> installation set is built.
>>>>
>>>> All that is needed is a list of extensions that are to be bundled for
>>>> each language. At the moment this list only contains entries for
>>>> english
>>>> and german.
>>>>
>>>> If you want to have dictionaries included for other languages then you
>>>> can do that in one of several ways:
>>>>
>>>> - Edit [1] in the confluence wiki and then tell me about it so that I
>>>> can update the main/extensions.lst file. The important part is to
>>>> provide working URLs int the "Upstream link" comment. The URLs may,
>>>> however, contain redirections (like the ones from
>>>> http://extensions.services.openoffice.org/en/dictionaries).
>>>> Note that you can edit this wiki only when you are a commiter.
>>>>
>>>> - Reply to this message on ooo-dev or personally to me. Again, it is
>>>> important that I get working URLs.
>>>>
>>>> - Edit main/extensions.lst yourself. I tried to document the format in
>>>> [2] but it should be pretty clear just by looking at extensions.lst.
>>>>
>>>>
>>>> Best regards,
>>>> Andre
>>>>
>>>>
>>>> [1]
>>>> https://cwiki.apache.org/confluence/display/OOOUSERS/Bundled+Writing+Aids
>>>>
>>>>
>>>> [2]
>>>> http://wiki.services.openoffice.org/wiki/Build_Bootstrapping#extensions.lst
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
Re: [RELEASE] Dictionary extensions
Posted by Simon Brouwer <si...@brousant.nl>.
Hi Andre,
There is one at http://en-gb.pyxidium.co.uk/dictionary/OOo.php but the
zip just contains the .dic and .aff files; it is not in .oxt format.
The readme states the files are derived from lgpl sources and therefore
lgpl as well.
If nothing better is found, I could have a go at wrapping a .oxt around it.
Best regards,
Simon
Op 26-3-2012 11:46, Andre Fischer schreef:
> On 23.03.2012 22:15, Simon Brouwer wrote:
>> Hi Andre,
>>
>> I think in a Dutch AOO the following languages should be bundled:
>> Dutch (nl_NL)
>> English (en_GB and en_US)
>> French (fr_FR)
>> German (de_DE)
>
> After reading your mail again, I suppose that you want dictionaries
> nl_NL, en_GB, en_US, fr_FR, and de_DE added for dutch.
>
> I can add all of these except en_GB. The link on [1] lead to dead links
> (on an ftp server that is not online anymore.)
>
> I will update the Wiki and main/extensions.lst.
>
> If anyone finds a working en_GB dictionary, please speak up.
>
> -Andre
>
>>
>> I have added URLs of these in [1] if missing.
>>
>> Best regards
>> Simon.
>>
>> Op 22-3-2012 10:25, Andre Fischer schreef:
>>> Hi all,
>>>
>>> I need your help.
>>>
>>> We are now able to include extensions -- dictionaries and others -- into
>>> installation sets, depending on the language(s) for which an
>>> installation set is built.
>>>
>>> All that is needed is a list of extensions that are to be bundled for
>>> each language. At the moment this list only contains entries for english
>>> and german.
>>>
>>> If you want to have dictionaries included for other languages then you
>>> can do that in one of several ways:
>>>
>>> - Edit [1] in the confluence wiki and then tell me about it so that I
>>> can update the main/extensions.lst file. The important part is to
>>> provide working URLs int the "Upstream link" comment. The URLs may,
>>> however, contain redirections (like the ones from
>>> http://extensions.services.openoffice.org/en/dictionaries).
>>> Note that you can edit this wiki only when you are a commiter.
>>>
>>> - Reply to this message on ooo-dev or personally to me. Again, it is
>>> important that I get working URLs.
>>>
>>> - Edit main/extensions.lst yourself. I tried to document the format in
>>> [2] but it should be pretty clear just by looking at extensions.lst.
>>>
>>>
>>> Best regards,
>>> Andre
>>>
>>>
>>> [1]
>>> https://cwiki.apache.org/confluence/display/OOOUSERS/Bundled+Writing+Aids
>>>
>>> [2]
>>> http://wiki.services.openoffice.org/wiki/Build_Bootstrapping#extensions.lst
>>>
>>>
>>>
>>
>>
>
--
Vriendelijke groet, Best regards,
Simon Brouwer
Re: [RELEASE] Dictionary extensions
Posted by Andre Fischer <af...@a-w-f.de>.
On 23.03.2012 22:15, Simon Brouwer wrote:
> Hi Andre,
>
> I think in a Dutch AOO the following languages should be bundled:
> Dutch (nl_NL)
> English (en_GB and en_US)
> French (fr_FR)
> German (de_DE)
After reading your mail again, I suppose that you want dictionaries
nl_NL, en_GB, en_US, fr_FR, and de_DE added for dutch.
I can add all of these except en_GB. The link on [1] lead to dead links
(on an ftp server that is not online anymore.)
I will update the Wiki and main/extensions.lst.
If anyone finds a working en_GB dictionary, please speak up.
-Andre
>
> I have added URLs of these in [1] if missing.
>
> Best regards
> Simon.
>
> Op 22-3-2012 10:25, Andre Fischer schreef:
>> Hi all,
>>
>> I need your help.
>>
>> We are now able to include extensions -- dictionaries and others -- into
>> installation sets, depending on the language(s) for which an
>> installation set is built.
>>
>> All that is needed is a list of extensions that are to be bundled for
>> each language. At the moment this list only contains entries for english
>> and german.
>>
>> If you want to have dictionaries included for other languages then you
>> can do that in one of several ways:
>>
>> - Edit [1] in the confluence wiki and then tell me about it so that I
>> can update the main/extensions.lst file. The important part is to
>> provide working URLs int the "Upstream link" comment. The URLs may,
>> however, contain redirections (like the ones from
>> http://extensions.services.openoffice.org/en/dictionaries).
>> Note that you can edit this wiki only when you are a commiter.
>>
>> - Reply to this message on ooo-dev or personally to me. Again, it is
>> important that I get working URLs.
>>
>> - Edit main/extensions.lst yourself. I tried to document the format in
>> [2] but it should be pretty clear just by looking at extensions.lst.
>>
>>
>> Best regards,
>> Andre
>>
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/OOOUSERS/Bundled+Writing+Aids
>> [2]
>> http://wiki.services.openoffice.org/wiki/Build_Bootstrapping#extensions.lst
>>
>>
>
>
Re: [RELEASE] Dictionary extensions
Posted by Andre Fischer <af...@a-w-f.de>.
On 23.03.2012 22:15, Simon Brouwer wrote:
> Hi Andre,
>
> I think in a Dutch AOO the following languages should be bundled:
> Dutch (nl_NL)
> English (en_GB and en_US)
> French (fr_FR)
> German (de_DE)
>
> I have added URLs of these in [1] if missing.
Thanks, I have updated the main/extensions.lst file accordingly.
Note that I have only added one dutch dictionary for nl_NL, if you want
dictionaries for other languages included, please update the Wiki page.
We have now dictionaries for these languages:
en
de, de_DE
nl_NL
fr_FR
it_IT
es_ES
-Andre
>
> Best regards
> Simon.
>
> Op 22-3-2012 10:25, Andre Fischer schreef:
>> Hi all,
>>
>> I need your help.
>>
>> We are now able to include extensions -- dictionaries and others -- into
>> installation sets, depending on the language(s) for which an
>> installation set is built.
>>
>> All that is needed is a list of extensions that are to be bundled for
>> each language. At the moment this list only contains entries for english
>> and german.
>>
>> If you want to have dictionaries included for other languages then you
>> can do that in one of several ways:
>>
>> - Edit [1] in the confluence wiki and then tell me about it so that I
>> can update the main/extensions.lst file. The important part is to
>> provide working URLs int the "Upstream link" comment. The URLs may,
>> however, contain redirections (like the ones from
>> http://extensions.services.openoffice.org/en/dictionaries).
>> Note that you can edit this wiki only when you are a commiter.
>>
>> - Reply to this message on ooo-dev or personally to me. Again, it is
>> important that I get working URLs.
>>
>> - Edit main/extensions.lst yourself. I tried to document the format in
>> [2] but it should be pretty clear just by looking at extensions.lst.
>>
>>
>> Best regards,
>> Andre
>>
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/OOOUSERS/Bundled+Writing+Aids
>> [2]
>> http://wiki.services.openoffice.org/wiki/Build_Bootstrapping#extensions.lst
>>
>>
>
>
Re: [RELEASE] Dictionary extensions
Posted by Simon Brouwer <si...@brousant.nl>.
Hi Andre,
I think in a Dutch AOO the following languages should be bundled:
Dutch (nl_NL)
English (en_GB and en_US)
French (fr_FR)
German (de_DE)
I have added URLs of these in [1] if missing.
Best regards
Simon.
Op 22-3-2012 10:25, Andre Fischer schreef:
> Hi all,
>
> I need your help.
>
> We are now able to include extensions -- dictionaries and others -- into
> installation sets, depending on the language(s) for which an
> installation set is built.
>
> All that is needed is a list of extensions that are to be bundled for
> each language. At the moment this list only contains entries for english
> and german.
>
> If you want to have dictionaries included for other languages then you
> can do that in one of several ways:
>
> - Edit [1] in the confluence wiki and then tell me about it so that I
> can update the main/extensions.lst file. The important part is to
> provide working URLs int the "Upstream link" comment. The URLs may,
> however, contain redirections (like the ones from
> http://extensions.services.openoffice.org/en/dictionaries).
> Note that you can edit this wiki only when you are a commiter.
>
> - Reply to this message on ooo-dev or personally to me. Again, it is
> important that I get working URLs.
>
> - Edit main/extensions.lst yourself. I tried to document the format in
> [2] but it should be pretty clear just by looking at extensions.lst.
>
>
> Best regards,
> Andre
>
>
> [1]
> https://cwiki.apache.org/confluence/display/OOOUSERS/Bundled+Writing+Aids
> [2]
> http://wiki.services.openoffice.org/wiki/Build_Bootstrapping#extensions.lst
>
--
Vriendelijke groet, Best regards,
Simon Brouwer
Re: [RELEASE] Dictionary extensions
Posted by Andre Fischer <af...@a-w-f.de>.
On 30.03.2012 10:45, Javier Sola wrote:
> Dear André,
>
> can you please include the Khmer (km_KH) dictionary for Khmer language.
>
> Please use the one in:
>
> http://extensions.services.openoffice.org/en/project/km_spellchecker
Done.
>
> Cheers,
>
> Javier
>
>
>
> On 3/29/12 8:49 PM, Andre Fischer wrote:
>> Current Status: Bundled dictionaries for ui languages:
>>
>> ui language dictionaries
>> --------------------------------------------------------
>> da da
>>
>> de_AT de_AT
>> de_CH de_CH
>> de,de_DE de_DE, de_AT, de_CH, it, fr, en
>>
>> en en, en_CA, en_US, en_AU, en_ZA, en_NZ
>>
>> es es
>>
>> fr fr
>>
>> it it
>>
>> nl en_US, fr, de_DE
>>
>> no no
>>
>> ro ro
>>
>> ru ru, en_US, de
>>
>> sl sl
>>
>>
>> Find details at [1]. If a language is not listed in the first column
>> then no dictionary will be bundled.
>>
>>
>> Ongoing: Italian team is working on the set of dictionaries to include
>> for "it".
>>
>>
>> _Call for Action:_ If your language is missing in this list, or you want
>> more dictionaries bundled for it then please reply to this thread. It
>> will not take much of your time.
>>
>>
>> Best regards,
>> Andre
>>
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/OOOUSERS/Bundled+Writing+Aids
>>
>>
>
Re: [RELEASE] Dictionary extensions
Posted by Javier Sola <li...@khmeros.info>.
Dear André,
can you please include the Khmer (km_KH) dictionary for Khmer language.
Please use the one in:
http://extensions.services.openoffice.org/en/project/km_spellchecker
Cheers,
Javier
On 3/29/12 8:49 PM, Andre Fischer wrote:
> Current Status: Bundled dictionaries for ui languages:
>
> ui language dictionaries
> --------------------------------------------------------
> da da
>
> de_AT de_AT
> de_CH de_CH
> de,de_DE de_DE, de_AT, de_CH, it, fr, en
>
> en en, en_CA, en_US, en_AU, en_ZA, en_NZ
>
> es es
>
> fr fr
>
> it it
>
> nl en_US, fr, de_DE
>
> no no
>
> ro ro
>
> ru ru, en_US, de
>
> sl sl
>
>
> Find details at [1]. If a language is not listed in the first column
> then no dictionary will be bundled.
>
>
> Ongoing: Italian team is working on the set of dictionaries to include
> for "it".
>
>
> _Call for Action:_ If your language is missing in this list, or you want
> more dictionaries bundled for it then please reply to this thread. It
> will not take much of your time.
>
>
> Best regards,
> Andre
>
>
> [1]
> https://cwiki.apache.org/confluence/display/OOOUSERS/Bundled+Writing+Aids
>
>
Re: [RELEASE] Dictionary extensions
Posted by Gianluca Turconi <gt...@letturefantastiche.com>.
In data 02 aprile 2012 alle ore 17:30:40, Andre Fischer <af...@a-w-f.de> ha
scritto:
> Added English dictionary (plain en, no -US or other) for Italian UI.
Does anybody know why this dictionary is simply labeled "en", while
comments here:
http://extensions.services.openoffice.org/en/project/dict-en-fixed
say that it's US-spelling only?
Regards,
--
Gianluca Turconi
Lettura gratuita o acquisto di libri e racconti di fantascienza,
fantasy, horror, noir, narrativa fantastica e tradizionale:
http://www.letturefantastiche.com/
Re: [RELEASE] Dictionary extensions
Posted by Andrea Pescetti <pe...@apache.org>.
Ariel Constenla-Haile wrote:
> checking the MD5 sounds better.
> The attached patch seems to fix the issue (it updated 8 extensions on
> the first run, none on the second).
Great! The patch was apparently removed by the mailing list filters, but
I opened an issue for this
https://issues.apache.org/ooo/show_bug.cgi?id=119229
and you can attach it there.
Thanks,
Andrea.
Re: [RELEASE] Dictionary extensions
Posted by Ariel Constenla-Haile <ar...@apache.org>.
Hi Andrea,
On Sun, Apr 15, 2012 at 7:29 AM, Andrea Pescetti <pe...@apache.org> wrote:
> Andrea Pescetti wrote:
>>
>> To address Ariel's concerns: this is independent of the
>> file name, since the Extensions website stores new revisions in
>> different directories (just look at the diff above; it should be clear).
>
>
> No, actually something is wrong here. I assumed that the script would
> download the file again if the checksum did not match the one listed in
> extensions.lst (which seems the reasonable behavior to me).
>
> But this didn't happen for the Italian dictionary in r1325589, just checked.
> So indeed, as Ariel says, we have two possible workarounds (clear the local
> mirror of extensions before build; rename extensions to be downloaded) but
> the solution would be to enforce that the MD5 matches the expected one from
> extensions.lst and, if it doesn't, to download the extension again.
checking the MD5 sounds better.
The attached patch seems to fix the issue (it updated 8 extensions on
the first run, none on the second).
Regards
Re: [RELEASE] Dictionary extensions
Posted by Andrea Pescetti <pe...@apache.org>.
Andrea Pescetti wrote:
> To address Ariel's concerns: this is independent of the
> file name, since the Extensions website stores new revisions in
> different directories (just look at the diff above; it should be clear).
No, actually something is wrong here. I assumed that the script would
download the file again if the checksum did not match the one listed in
extensions.lst (which seems the reasonable behavior to me).
But this didn't happen for the Italian dictionary in r1325589, just
checked. So indeed, as Ariel says, we have two possible workarounds
(clear the local mirror of extensions before build; rename extensions to
be downloaded) but the solution would be to enforce that the MD5 matches
the expected one from extensions.lst and, if it doesn't, to download the
extension again.
Regards,
Andrea.
Re: [RELEASE] Dictionary extensions
Posted by Andrea Pescetti <pe...@apache.org>.
RGB ES wrote:
> There is a new version (0.6) for the Spanish dictionaries
> http://extensions.services.openoffice.org/project/es_ES-dicts
> I remember reading somewhere that dictionaries are downloaded by the
> build script and in that case next build will have the updated
> versions. Is that right?
Only if extensions.lst is updated. See
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/extensions.lst?r1=1309339&r2=1309605
for an example. To address Ariel's concerns: this is independent of the
file name, since the Extensions website stores new revisions in
different directories (just look at the diff above; it should be clear).
Regards,
Andrea.
Re: [RELEASE] Dictionary extensions
Posted by Andre Fischer <af...@a-w-f.de>.
On 16.04.2012 17:33, Ariel Constenla-Haile wrote:
> On Mon, Apr 16, 2012 at 01:37:45PM +0800, Andre Fischer wrote:
>> As for the downloaded extension. I see this problem as an
>> inconvenience at best. For a new extension you have to update the
>> main/extensions.lst file anyway, so that the new MD5 sum is used.
>> If you do a clean build then everything is fine.
>
> That's not the case, unless by clean build you mean removing the whole
> source tree and checking the source again.
That is indeed what I meant.
> Reading
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Developer+Snapshots#AOO3.4UnofficialDeveloperSnapshots-buildflags
> it does not seem the case with the MacOS script, and I do (only) clean
> the source tree:
>
> cd trunk
> rm -rf */*/unxlngx6.pro
> rm -rf */*/unxlngi6.pro
> rm -rf main/solver/*/unxlngx6.pro
> rm -rf main/solver/*/unxlngi6.pro
I prefer
rm -rf main/solver
cd instsetoo_native
build --prepare --from solenv
but that would not solve the problem either.
>
> That's what I understand as a clean build.
> Of course I can remove the whole source tree and check it again, but you
> can not expect everyone building AOO to do so.
No, I guess not. I admit that the current behavior has to be improved.
I will do that after the 3.4 release.
>
>> The described problem occurs only if one tries to save time by
>> reusing previously downloaded extensions.
>
> The time is saved by not checking out the whole source tree, not the
> previously downloaded extensions, they are downloaded to a folder that
> contains source.
You save time by
- not checking out the source tree
- not downloading source tar balls
- not downloading dictionaries/extensions
As I said above, I will improve this after the release.
Something like:
Download extension if
- it is missing from ext_sources/
- the extension in ext_sources/ has a different MD5 checksum from
the one in main/extensions.lst
Other, better ideas?
Re: [RELEASE] Dictionary extensions
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Mon, Apr 16, 2012 at 01:37:45PM +0800, Andre Fischer wrote:
> As for the downloaded extension. I see this problem as an
> inconvenience at best. For a new extension you have to update the
> main/extensions.lst file anyway, so that the new MD5 sum is used.
> If you do a clean build then everything is fine.
That's not the case, unless by clean build you mean removing the whole
source tree and checking the source again.
Reading
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Developer+Snapshots#AOO3.4UnofficialDeveloperSnapshots-buildflags
it does not seem the case with the MacOS script, and I do (only) clean
the source tree:
cd trunk
rm -rf */*/unxlngx6.pro
rm -rf */*/unxlngi6.pro
rm -rf main/solver/*/unxlngx6.pro
rm -rf main/solver/*/unxlngi6.pro
That's what I understand as a clean build.
Of course I can remove the whole source tree and check it again, but you
can not expect everyone building AOO to do so.
> The described problem occurs only if one tries to save time by
> reusing previously downloaded extensions.
The time is saved by not checking out the whole source tree, not the
previously downloaded extensions, they are downloaded to a folder that
contains source.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [RELEASE] Dictionary extensions
Posted by Andre Fischer <af...@a-w-f.de>.
On 15.04.2012 23:49, Andrea Pescetti wrote:
> Rob Weir wrote:
>[...]
>> So if you think that
>> https://issues.apache.org/ooo/show_bug.cgi?id=119229 is a
>> release-blocking issue, then you need to make your case on that now.
>
> I won't. The effect, as far as the Italian dictionary is concerned, is
> not so big. But then we might discover that, due to that bug, we are
> bundling different versions of the Presentation Minimizer, or any other
> bundled extension, across different operating systems, and the bug might
> need to be re-evaluated.
We do not use MD5 checksums for the internal extensions like presenter
console or minimizer. Their current version is always used.
As for the downloaded extension. I see this problem as an inconvenience
at best. For a new extension you have to update the main/extensions.lst
file anyway, so that the new MD5 sum is used.
If you do a clean build then everything is fine.
The described problem occurs only if one tries to save time by reusing
previously downloaded extensions.
But I agree that a MD5 mismatch should be handled more gracefully. That
is something that should be fixed after the 3.4 release.
-Andre
Re: [RELEASE] Planning QA activities
Posted by xia zhao <li...@gmail.com>.
2012/4/16 Andrea Pescetti <pe...@apache.org>
> On 16/04/2012 xia zhao wrote:
>
>> 2012/4/16 Andrea Pescetti
>>
>> Sure, and it was great work. But those tests were run on versions that are
>>> now quite outdated. Example: the spell check test asks you to verify that
>>> no spell check is available and that dictionaries have been removed
>>> accurately, while we all know that things are quite different in current
>>> builds.
>>>
>> How do you means "tests were run on versions that are now quite outdated"?
>>
>
> http://wiki.services.**openoffice.org/wiki/QA/**TestCases/<http://wiki.services.openoffice.org/wiki/QA/TestCases/>has several testcases that would only apply to older builds (like: testing
> removal of dictionaries, but these are now bundled; testing removal of
> fonts, but these are now replaced; testing removal of HTTP features, but in
> the meantime those have been replaced too).
> This wiki page is less update. Originally we plan using wiki to record
> test cases and test result. But seems it isn't productive. Volunteers
> prefer to do testing and report the issues and result either by OOO-dev
> mail list or by BugZilla.And both test case page and test result page are
> less to be updated. It's better to use one test case management tool to
> track the progress. And I am planning propose one tool TestLink to
> community. For QA status based on scheduled build. You'd better checking
> the QA weekly status report.
>
> 1) Full QA is run on what we release. We need to ensure that OpenOffice
>>> works now, not that previous builds worked.
>>>
>> Agree if the "Full" here means test matrix on full platforms and full
>> langauges. The "OpenOffice" you means here I understand is AOO. For AOO,
>> the problem is we lost manual test cases
>>
>
> I wouldn't despair that we get them back at some point: as I wrote a long
> time ago, it would be enough to receive the test cases, the infrastructure
> for running them can be replaced.
>
New automation running infrastructure is developed and easy for volunteers
to develop new scripts. With more and more automation test cases developed
we can cover more and more regression testing.
>
> Regards,
> Andrea.
>
Re: [RELEASE] Planning QA activities
Posted by Andrea Pescetti <pe...@apache.org>.
On 16/04/2012 xia zhao wrote:
> 2012/4/16 Andrea Pescetti
>> Sure, and it was great work. But those tests were run on versions that are
>> now quite outdated. Example: the spell check test asks you to verify that
>> no spell check is available and that dictionaries have been removed
>> accurately, while we all know that things are quite different in current
>> builds.
> How do you means "tests were run on versions that are now quite outdated"?
http://wiki.services.openoffice.org/wiki/QA/TestCases/ has several
testcases that would only apply to older builds (like: testing removal
of dictionaries, but these are now bundled; testing removal of fonts,
but these are now replaced; testing removal of HTTP features, but in the
meantime those have been replaced too).
>> 1) Full QA is run on what we release. We need to ensure that OpenOffice
>> works now, not that previous builds worked.
> Agree if the "Full" here means test matrix on full platforms and full
> langauges. The "OpenOffice" you means here I understand is AOO. For AOO,
> the problem is we lost manual test cases
I wouldn't despair that we get them back at some point: as I wrote a
long time ago, it would be enough to receive the test cases, the
infrastructure for running them can be replaced.
Regards,
Andrea.
Re: [RELEASE] Planning QA activities (was: Dictionary extensions)
Posted by xia zhao <li...@gmail.com>.
2012/4/16 Andrea Pescetti <pe...@apache.org>
> On 15/04/2012 Rob Weir wrote:
>
>> On Sun, Apr 15, 2012 at 11:49 AM, Andrea Pescetti wrote:
>>
>>> Historically, OpenOffice.org produced a numbered Release Candidate
>>> (OpenOffice.org 3.3 had ten, RC1 to RC10) that was made available to the
>>> community exactly for the purpose of looking for unknown bugs. QA
>>> activities
>>> were planned for the RC phase and, after a few days of availability, a RC
>>> was approved as final or rejected (and the Release Manager could, and at
>>> times did, include fixes for previously known bugs that had been
>>> accumulating and that were significant; none of them was a blocker in
>>> itself, but each of them would have caused problems to users, so their
>>> combined effect was blocking the release).
>>>
>> That is what we've been doing with the dev snapsots builds. Surely
>> you've seen the QA work Lily has done with testing them?
>>
>
> Sure, and it was great work. But those tests were run on versions that are
> now quite outdated. Example: the spell check test asks you to verify that
> no spell check is available and that dictionaries have been removed
> accurately, while we all know that things are quite different in current
> builds.
>
How do you means "tests were run on versions that are now quite outdated"?
We are doing regressiont testing continuously. Switch build do different
feature regressiont esting. For RC build, I don't think the fulll
regression is reasonable, more important, it is instalation, extenson, plus
some small regressiont testing. The full regressionte testig should be done
before one RC build is ready for vote.
>
> The traditional OpenOffice.org Quality Assurance process had two features
> that I'd like to keep:
>
> 1) Full QA is run on what we release. We need to ensure that OpenOffice
> works now, not that previous builds worked.
>
Agree if the "Full" here means test matrix on full platforms and full
langauges. The "OpenOffice" you means here I understand is AOO. For AOO,
the problem is we lost manual test cases, so general regression testing is
done against AOO builds. I belive these testing results can be taken as
evidence of what AOO works now.
>
> 2) The community at large is involved in testing, in a specific short
> period just before the release. If "Release Candidate" has a different
> meaning now, call it the "Pre-Release Phase", that will end with a "Release
> Candidate" we can vote on rather confidently. We can't rely on volunteers
> doing QA on a regular basis, but we can very easily find volunteers willing
> to stress-test a "nearly final" version in a well defined timeframe (1-2
> weeks).
> I agree you on this point ans it is what we do now. You may check the RC
> build testing plan. QA volunteers will testing RC build for one week,
> meanwhile, all volunteers can do stress-test against RC build before he/she
> gives vote.
>
Lily
> I would keep this as a basis for discussing how to structure QA activities
> in future (after 3.4), if others agree.
>
> Regards,
> Andrea.
>
Re: [RELEASE] Planning QA activities
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 4/16/12 12:40 AM, Rob Weir wrote:
> On Sun, Apr 15, 2012 at 6:22 PM, Andrea Pescetti<pe...@apache.org> wrote:
>> On 15/04/2012 Rob Weir wrote:
>>>
>>> On Sun, Apr 15, 2012 at 11:49 AM, Andrea Pescetti wrote:
>>>>
>>>> Historically, OpenOffice.org produced a numbered Release Candidate
>>>> (OpenOffice.org 3.3 had ten, RC1 to RC10) that was made available to the
>>>> community exactly for the purpose of looking for unknown bugs. QA
>>>> activities
>>>> were planned for the RC phase and, after a few days of availability, a RC
>>>> was approved as final or rejected (and the Release Manager could, and at
>>>> times did, include fixes for previously known bugs that had been
>>>> accumulating and that were significant; none of them was a blocker in
>>>> itself, but each of them would have caused problems to users, so their
>>>> combined effect was blocking the release).
>>>
>>> That is what we've been doing with the dev snapsots builds. Surely
>>> you've seen the QA work Lily has done with testing them?
>>
>>
>> Sure, and it was great work. But those tests were run on versions that are
>> now quite outdated. Example: the spell check test asks you to verify that no
>> spell check is available and that dictionaries have been removed accurately,
>> while we all know that things are quite different in current builds.
>>
>> The traditional OpenOffice.org Quality Assurance process had two features
>> that I'd like to keep:
>>
>> 1) Full QA is run on what we release. We need to ensure that OpenOffice
>> works now, not that previous builds worked.
>>
>
> "Full" to me means a test matrix on all platforms, all functions, all
> languages, and includes performance, interop and other tests. A full
> test pass probably takes 4-6 weeks if we do it right. I don't think
> we have the opportunity to do more than one "full" test pass per
> release. But this should happen much earlier, right after a "feature
> freeze" when all features targeted for a release have been checked in.
>
>> 2) The community at large is involved in testing, in a specific short period
>> just before the release. If "Release Candidate" has a different meaning now,
>> call it the "Pre-Release Phase", that will end with a "Release Candidate" we
>> can vote on rather confidently. We can't rely on volunteers doing QA on a
>> regular basis, but we can very easily find volunteers willing to stress-test
>> a "nearly final" version in a well defined timeframe (1-2 weeks).
>>
>> I would keep this as a basis for discussing how to structure QA activities
>> in future (after 3.4), if others agree.
>>
>
> This is only a fraction of the picture. We also need to consider what
> changes are allowed, and how those changes are reviewed, as we
> progress toward a Release Candidate. That is a critical part of how
> we maintain quality. If committers are checking in whatever they feel
> like, up to the day we have a RC, then we will have serious quality
> problems.
>
> When we changing code we "invalidate" prior testing. Not in an
> absolute sense, for most code changes there is an test impact, and
> some portion of the "full test" needs to be redone, to verify both the
> fix, but also that we did not break anything else. Again, this
> requires discipline from committers. "Last minute" feature work, or
> even undisciplined bug fixing, can cause more problems than it fixes.
>
> So I think we want the trunk to be fee CTR up to a certain point
> (feature freeze?) and after that point only changes that are
> accompanied by a BZ issue are allowed, but still CTR. Then at some
> point, after the main test pass is complete, we start prioritizing
> bugs as we create snapshot builds. We gradually raise the level
> required for bugs to be accepted. P3, P2, P1. In the final weeks we
> fix only marked release blockers. Once we have the RC build we
> branch the code. At that point (and maybe even earlier) we switch to
> RTC, e.g., no changes are allowed unless they are reviewed first.
>
> Was anything like this done before with OOo?
Yes, more or less in a similar way and I think it is a good way to
achieve a high quality product.
And on the other hand we should try to provide as much as possible
automated testing. And volunteers should do manual testing not only RC
candidates. A continuous testing on dev snapshots would be very much
appreciated if possible.
Juergen
>
> -Rob
>
>> Regards,
>> Andrea.
Re: [RELEASE] Planning QA activities (was: Dictionary extensions)
Posted by Rob Weir <ro...@apache.org>.
On Sun, Apr 15, 2012 at 6:22 PM, Andrea Pescetti <pe...@apache.org> wrote:
> On 15/04/2012 Rob Weir wrote:
>>
>> On Sun, Apr 15, 2012 at 11:49 AM, Andrea Pescetti wrote:
>>>
>>> Historically, OpenOffice.org produced a numbered Release Candidate
>>> (OpenOffice.org 3.3 had ten, RC1 to RC10) that was made available to the
>>> community exactly for the purpose of looking for unknown bugs. QA
>>> activities
>>> were planned for the RC phase and, after a few days of availability, a RC
>>> was approved as final or rejected (and the Release Manager could, and at
>>> times did, include fixes for previously known bugs that had been
>>> accumulating and that were significant; none of them was a blocker in
>>> itself, but each of them would have caused problems to users, so their
>>> combined effect was blocking the release).
>>
>> That is what we've been doing with the dev snapsots builds. Surely
>> you've seen the QA work Lily has done with testing them?
>
>
> Sure, and it was great work. But those tests were run on versions that are
> now quite outdated. Example: the spell check test asks you to verify that no
> spell check is available and that dictionaries have been removed accurately,
> while we all know that things are quite different in current builds.
>
> The traditional OpenOffice.org Quality Assurance process had two features
> that I'd like to keep:
>
> 1) Full QA is run on what we release. We need to ensure that OpenOffice
> works now, not that previous builds worked.
>
"Full" to me means a test matrix on all platforms, all functions, all
languages, and includes performance, interop and other tests. A full
test pass probably takes 4-6 weeks if we do it right. I don't think
we have the opportunity to do more than one "full" test pass per
release. But this should happen much earlier, right after a "feature
freeze" when all features targeted for a release have been checked in.
> 2) The community at large is involved in testing, in a specific short period
> just before the release. If "Release Candidate" has a different meaning now,
> call it the "Pre-Release Phase", that will end with a "Release Candidate" we
> can vote on rather confidently. We can't rely on volunteers doing QA on a
> regular basis, but we can very easily find volunteers willing to stress-test
> a "nearly final" version in a well defined timeframe (1-2 weeks).
>
> I would keep this as a basis for discussing how to structure QA activities
> in future (after 3.4), if others agree.
>
This is only a fraction of the picture. We also need to consider what
changes are allowed, and how those changes are reviewed, as we
progress toward a Release Candidate. That is a critical part of how
we maintain quality. If committers are checking in whatever they feel
like, up to the day we have a RC, then we will have serious quality
problems.
When we changing code we "invalidate" prior testing. Not in an
absolute sense, for most code changes there is an test impact, and
some portion of the "full test" needs to be redone, to verify both the
fix, but also that we did not break anything else. Again, this
requires discipline from committers. "Last minute" feature work, or
even undisciplined bug fixing, can cause more problems than it fixes.
So I think we want the trunk to be fee CTR up to a certain point
(feature freeze?) and after that point only changes that are
accompanied by a BZ issue are allowed, but still CTR. Then at some
point, after the main test pass is complete, we start prioritizing
bugs as we create snapshot builds. We gradually raise the level
required for bugs to be accepted. P3, P2, P1. In the final weeks we
fix only marked release blockers. Once we have the RC build we
branch the code. At that point (and maybe even earlier) we switch to
RTC, e.g., no changes are allowed unless they are reviewed first.
Was anything like this done before with OOo?
-Rob
> Regards,
> Andrea.
[RELEASE] Planning QA activities (was: Dictionary extensions)
Posted by Andrea Pescetti <pe...@apache.org>.
On 15/04/2012 Rob Weir wrote:
> On Sun, Apr 15, 2012 at 11:49 AM, Andrea Pescetti wrote:
>> Historically, OpenOffice.org produced a numbered Release Candidate
>> (OpenOffice.org 3.3 had ten, RC1 to RC10) that was made available to the
>> community exactly for the purpose of looking for unknown bugs. QA activities
>> were planned for the RC phase and, after a few days of availability, a RC
>> was approved as final or rejected (and the Release Manager could, and at
>> times did, include fixes for previously known bugs that had been
>> accumulating and that were significant; none of them was a blocker in
>> itself, but each of them would have caused problems to users, so their
>> combined effect was blocking the release).
> That is what we've been doing with the dev snapsots builds. Surely
> you've seen the QA work Lily has done with testing them?
Sure, and it was great work. But those tests were run on versions that
are now quite outdated. Example: the spell check test asks you to verify
that no spell check is available and that dictionaries have been removed
accurately, while we all know that things are quite different in current
builds.
The traditional OpenOffice.org Quality Assurance process had two
features that I'd like to keep:
1) Full QA is run on what we release. We need to ensure that OpenOffice
works now, not that previous builds worked.
2) The community at large is involved in testing, in a specific short
period just before the release. If "Release Candidate" has a different
meaning now, call it the "Pre-Release Phase", that will end with a
"Release Candidate" we can vote on rather confidently. We can't rely on
volunteers doing QA on a regular basis, but we can very easily find
volunteers willing to stress-test a "nearly final" version in a well
defined timeframe (1-2 weeks).
I would keep this as a basis for discussing how to structure QA
activities in future (after 3.4), if others agree.
Regards,
Andrea.
Re: [RELEASE] Dictionary extensions
Posted by Rob Weir <ro...@apache.org>.
On Sun, Apr 15, 2012 at 11:49 AM, Andrea Pescetti <pe...@apache.org> wrote:
> Rob Weir wrote:
>>
>> Let's make sure we agree on what a Release Candidate is. A RC is a
>> build we (and the IPMC) vote on. If the vote passes then we release.
>> There are no vetoes in this vote.
>
>
> We agree on this.
>
>
>> The RC is not the time to start looking for new bugs, or to raise
>> already known bugs.
>
>
> Then we have a different understanding of what the target public of a RC is,
> and this is likely due to a difference in processes.
>
You read what a Release Candidate at Apache is here:
http://www.apache.org/dev/release.html#release-typeso
> Historically, OpenOffice.org produced a numbered Release Candidate
> (OpenOffice.org 3.3 had ten, RC1 to RC10) that was made available to the
> community exactly for the purpose of looking for unknown bugs. QA activities
> were planned for the RC phase and, after a few days of availability, a RC
> was approved as final or rejected (and the Release Manager could, and at
> times did, include fixes for previously known bugs that had been
> accumulating and that were significant; none of them was a blocker in
> itself, but each of them would have caused problems to users, so their
> combined effect was blocking the release).
>
That is what we've been doing with the dev snapsots builds. Surely
you've seen the QA work Lily has done with testing them?
> Now, if I get it correctly, the target public is just people who have to
> vote on a release and not the community at large, so QA tests are expected
> to be run on an earlier version, or anyway it is not expected that the RC
> phase will be the peak of QA activities. Right? (In other words: the first
> RC in earlier times had a ~80% chance of being rejected; here the first RC
> would have high chances to be approved).
>
Anyone is welcome to vote on a Release Candidate, but only IPMC votes
are binding. The RC is not the "peak of QA activities". All testing
should already be complete as a condition of having a RC. The RC
would have only limited regression testing, to make sure that any last
minute fixes for release-blockers did not introduce new bugs.
IMHO, the RC should have a high probability of approval from the PPMC,
in terms of product quality and functionality. We should be proud of
what we've accomplished. But since this is our first podling release,
there is a chance the IPMC will find some formal defect in the release
(license, notice, packaging, etc.) that could require us to cut a 2nd
RC.
>
>> If you are aware of a bug that must be fixed
>> before we release, then you should have already entered it as a
>> release-blocking issue. You should not wait for the RC build.
>
>
> Everything that is confirmed, P2, a bug, and different from OpenOffice.org
> 3.3 should either be a blocker or deserve a line in the Release Notes. Do we
> agree on this, or any reasonable tweaking of it?
Nothing is proposed as a release-blocking issue unless the release
blocker flag is set in BZ. Regressions from 3.3.0 and high priority
bugs are reasonable criteria for proposing a release blocker. But it
does not become a release blocker unless the flag is set and the issue
is discussed on the list. That is the process that we've been
following.
See, for example, this post:
http://markmail.org/thread/oj4mvgoltklba7pc
> The icon problem https://issues.apache.org/ooo/show_bug.cgi?id=119208 falls
> in this case, so I just commented on the relevant thread.
>
OK.
>
>> So if you think that
>> https://issues.apache.org/ooo/show_bug.cgi?id=119229 is a
>> release-blocking issue, then you need to make your case on that now.
>
>
> I won't. The effect, as far as the Italian dictionary is concerned, is not
> so big. But then we might discover that, due to that bug, we are bundling
> different versions of the Presentation Minimizer, or any other bundled
> extension, across different operating systems, and the bug might need to be
> re-evaluated.
>
> Regards,
> Andrea.
Re: [RELEASE] Dictionary extensions
Posted by Andrea Pescetti <pe...@apache.org>.
Rob Weir wrote:
> Let's make sure we agree on what a Release Candidate is. A RC is a
> build we (and the IPMC) vote on. If the vote passes then we release.
> There are no vetoes in this vote.
We agree on this.
> The RC is not the time to start looking for new bugs, or to raise
> already known bugs.
Then we have a different understanding of what the target public of a RC
is, and this is likely due to a difference in processes.
Historically, OpenOffice.org produced a numbered Release Candidate
(OpenOffice.org 3.3 had ten, RC1 to RC10) that was made available to the
community exactly for the purpose of looking for unknown bugs. QA
activities were planned for the RC phase and, after a few days of
availability, a RC was approved as final or rejected (and the Release
Manager could, and at times did, include fixes for previously known bugs
that had been accumulating and that were significant; none of them was a
blocker in itself, but each of them would have caused problems to users,
so their combined effect was blocking the release).
Now, if I get it correctly, the target public is just people who have to
vote on a release and not the community at large, so QA tests are
expected to be run on an earlier version, or anyway it is not expected
that the RC phase will be the peak of QA activities. Right? (In other
words: the first RC in earlier times had a ~80% chance of being
rejected; here the first RC would have high chances to be approved).
> If you are aware of a bug that must be fixed
> before we release, then you should have already entered it as a
> release-blocking issue. You should not wait for the RC build.
Everything that is confirmed, P2, a bug, and different from
OpenOffice.org 3.3 should either be a blocker or deserve a line in the
Release Notes. Do we agree on this, or any reasonable tweaking of it?
The icon problem https://issues.apache.org/ooo/show_bug.cgi?id=119208
falls in this case, so I just commented on the relevant thread.
> So if you think that
> https://issues.apache.org/ooo/show_bug.cgi?id=119229 is a
> release-blocking issue, then you need to make your case on that now.
I won't. The effect, as far as the Italian dictionary is concerned, is
not so big. But then we might discover that, due to that bug, we are
bundling different versions of the Presentation Minimizer, or any other
bundled extension, across different operating systems, and the bug might
need to be re-evaluated.
Regards,
Andrea.
Re: [RELEASE] Dictionary extensions
Posted by Rob Weir <ro...@apache.org>.
On Sun, Apr 15, 2012 at 10:16 AM, Andrea Pescetti <pe...@apache.org> wrote:
> Rob Weir wrote:
>>
>> I see that Andrea has entered an issue in BZ for this:
>> https://issues.apache.org/ooo/show_bug.cgi?id=119229
>> But no one has explained what the bug actual is.
>
>
> The description I gave there is a rather accurate description of the bug
> itself, but indeed it doesn't explain its effects.
>
> The effect is: if I modify the OpenOffice sources (extensions.lst) in order
> to use a newer version of the Italian (or Spanish) dictionary, by providing
> a new download link and a new MD5 checksum for it, the build system (unless
> we are building on a completely clean system, and this is a different
> problem) will continue to use any previously downloaded version. So the most
> recent builds from Ariel, for example, do not bundle the latest Italian
> dictionary and are not consistent with the latest source code.
>
>
>> And no one has set the release blocker flag.
>
>
> The dictionary update is a problem but the inconsistency with the source
> code is probably a bigger problem.
>
> As for release blockers, I honestly expect that when RC1 is out we will have
> a look at significant bugs that emerge (including a couple of existing bugs
> that might not be release blockers by themselves but are surely significant,
> like this one
> https://issues.apache.org/ooo/show_bug.cgi?id=119229 and the icons
> https://issues.apache.org/ooo/show_bug.cgi?id=119208 ) and, if we have
> several of them, produce a RC2 instead of listing, say, ten "Known bugs" in
> the Release notes.
>
Let's make sure we agree on what a Release Candidate is. A RC is a
build we (and the IPMC) vote on. If the vote passes then we release.
There are no vetoes in this vote.
The RC is not the time to start looking for new bugs, or to raise
already known bugs. If you are aware of a bug that must be fixed
before we release, then you should have already entered it as a
release-blocking issue. You should not wait for the RC build.
So if you think that
https://issues.apache.org/ooo/show_bug.cgi?id=119229 is a
release-blocking issue, then you need to make your case on that now.
-Rob
> Regards,
> Andrea.
Re: [RELEASE] Dictionary extensions
Posted by Andrea Pescetti <pe...@apache.org>.
Rob Weir wrote:
> I see that Andrea has entered an issue in BZ for this:
> https://issues.apache.org/ooo/show_bug.cgi?id=119229
> But no one has explained what the bug actual is.
The description I gave there is a rather accurate description of the bug
itself, but indeed it doesn't explain its effects.
The effect is: if I modify the OpenOffice sources (extensions.lst) in
order to use a newer version of the Italian (or Spanish) dictionary, by
providing a new download link and a new MD5 checksum for it, the build
system (unless we are building on a completely clean system, and this is
a different problem) will continue to use any previously downloaded
version. So the most recent builds from Ariel, for example, do not
bundle the latest Italian dictionary and are not consistent with the
latest source code.
> And no one has set the release blocker flag.
The dictionary update is a problem but the inconsistency with the source
code is probably a bigger problem.
As for release blockers, I honestly expect that when RC1 is out we will
have a look at significant bugs that emerge (including a couple of
existing bugs that might not be release blockers by themselves but are
surely significant, like this one
https://issues.apache.org/ooo/show_bug.cgi?id=119229 and the icons
https://issues.apache.org/ooo/show_bug.cgi?id=119208 ) and, if we have
several of them, produce a RC2 instead of listing, say, ten "Known bugs"
in the Release notes.
Regards,
Andrea.
Re: [RELEASE] Dictionary extensions
Posted by Rob Weir <ro...@apache.org>.
On Sun, Apr 15, 2012 at 5:27 AM, RGB ES <rg...@gmail.com> wrote:
> There is a new version (0.6) for the Spanish dictionaries
>
> http://extensions.services.openoffice.org/project/es_ES-dicts
>
> I remember reading somewhere that dictionaries are downloaded by the
> build script and in that case next build will have the updated
> versions. Is that right?
>
The process we've been using is this:
1) Someone enters a defect report in BZ describing the issue and
setting the 3_4_release_blocker flag to "?"
2) Same person starts a thread on ooo-dev pointing to that BZ issue
and seeking consensus to treat that issue as a release blocker
3) If there is consensus that there is a release-blocking bug, then we
delay the release until we fix the bug
I see that Andrea has entered an issue in BZ for this:
https://issues.apache.org/ooo/show_bug.cgi?id=119229
But no one has explained what the bug actual is. And no one has set
the release blocker flag. The fact that we are not using a new
dictionary that came out a few days ago -- this is not a bug, IMHO.
That would be a feature enhancement, but we can do that in the next
release.
-Rob
> Regards
> Ricardo
Re: [RELEASE] Dictionary extensions
Posted by Ariel Constenla-Haile <ar...@gmail.com>.
On Sun, Apr 15, 2012 at 6:51 AM, RGB ES <rg...@gmail.com> wrote:
>>> There is a new version (0.6) for the Spanish dictionaries
>>>
>>> http://extensions.services.openoffice.org/project/es_ES-dicts
>>>
>>> I remember reading somewhere that dictionaries are downloaded by the
>>> build script
>>
>> yes, but they are downloaded to trunk/ext_sources/ (this means they
>> are not removed when you clean the source tree).
>>
>>> and in that case next build will have the updated
>>> versions. Is that right?
>>
>> at least the Linux builds won't have updated versions (just checked
>> the Changelog.txt and has 0.5 as top entry).
>> I see two options: the dictionaries should be downloaded to a location
>> that gets cleaned when cleaning the source tree; or tell the extension
>> developer to put the version on the file name: es_ES-0.6.oxt, then
>> update trunk/main/extensions.lst.
>>
>> Regards
>> Ariel
>
> The new version came out yesterday so maybe we are on a typical Murphy
> law application were the build script downloaded the data just a
> second before the update... ;)
though I build on Friday morning, it has nothing to do with the date:
if the downloadable extension is present, it won't be downloaded.
Regards
Ariel
Re: [RELEASE] Dictionary extensions
Posted by RGB ES <rg...@gmail.com>.
El día 15 de abril de 2012 11:43, Ariel Constenla-Haile
<ar...@apache.org> escribió:
> Hi Ricardo,
>
> On Sun, Apr 15, 2012 at 6:27 AM, RGB ES <rg...@gmail.com> wrote:
>> There is a new version (0.6) for the Spanish dictionaries
>>
>> http://extensions.services.openoffice.org/project/es_ES-dicts
>>
>> I remember reading somewhere that dictionaries are downloaded by the
>> build script
>
> yes, but they are downloaded to trunk/ext_sources/ (this means they
> are not removed when you clean the source tree).
>
>> and in that case next build will have the updated
>> versions. Is that right?
>
> at least the Linux builds won't have updated versions (just checked
> the Changelog.txt and has 0.5 as top entry).
> I see two options: the dictionaries should be downloaded to a location
> that gets cleaned when cleaning the source tree; or tell the extension
> developer to put the version on the file name: es_ES-0.6.oxt, then
> update trunk/main/extensions.lst.
>
> Regards
> Ariel
The new version came out yesterday so maybe we are on a typical Murphy
law application were the build script downloaded the data just a
second before the update... ;)
Regards
Ricardo
Re: [RELEASE] Dictionary extensions
Posted by Ariel Constenla-Haile <ar...@apache.org>.
Hi Ricardo,
On Sun, Apr 15, 2012 at 6:27 AM, RGB ES <rg...@gmail.com> wrote:
> There is a new version (0.6) for the Spanish dictionaries
>
> http://extensions.services.openoffice.org/project/es_ES-dicts
>
> I remember reading somewhere that dictionaries are downloaded by the
> build script
yes, but they are downloaded to trunk/ext_sources/ (this means they
are not removed when you clean the source tree).
> and in that case next build will have the updated
> versions. Is that right?
at least the Linux builds won't have updated versions (just checked
the Changelog.txt and has 0.5 as top entry).
I see two options: the dictionaries should be downloaded to a location
that gets cleaned when cleaning the source tree; or tell the extension
developer to put the version on the file name: es_ES-0.6.oxt, then
update trunk/main/extensions.lst.
Regards
Ariel
Re: [RELEASE] Dictionary extensions
Posted by RGB ES <rg...@gmail.com>.
There is a new version (0.6) for the Spanish dictionaries
http://extensions.services.openoffice.org/project/es_ES-dicts
I remember reading somewhere that dictionaries are downloaded by the
build script and in that case next build will have the updated
versions. Is that right?
Regards
Ricardo
Re: [RELEASE] Dictionary extensions
Posted by Gianluca Turconi <gt...@letturefantastiche.com>.
In data 05 aprile 2012 alle ore 18:37:25, Dennis E. Hamilton
<de...@acm.org> ha scritto:
> There are -en Writing Aids extensions that tend to bundle the variants
> in the same package. E.g., there will be en-US, en-GB, en-ZA, and
> others in the same .oxt.
Well, I've unzipped the "en" oxt package and it includes several English
spelling dictionaries (_AU _CA _GB _US _ZA), but only two hyphenation
files (_GB _US) and only one thesaurus (_US).
It's a rather complete tool, but the original package oxt description is
also rather misleading because it doesn't say before downloading what the
package exactly includes.
Anyway, for its inclusion into the Italian binary and from my point of
view, this package is better than what I thought since it includes the _GB
variant. :-)
Regards,
--
Gianluca Turconi
Lettura gratuita o acquisto di libri e racconti di fantascienza,
fantasy, horror, noir, narrativa fantastica e tradizionale:
http://www.letturefantastiche.com/
RE: [RELEASE] Dictionary extensions
Posted by "Dennis E. Hamilton" <de...@acm.org>.
There are -en Writing Aids extensions that tend to bundle the variants in the same package. E.g., there will be en-US, en-GB, en-ZA, and others in the same .oxt.
Is this not happening with the AOO Writing Aids?
- Dennis
-----Original Message-----
From: Gianluca Turconi [mailto:gt@letturefantastiche.com]
Sent: Thursday, April 05, 2012 00:13
To: ooo-dev@incubator.apache.org
Subject: Re: [RELEASE] Dictionary extensions
In data 02 aprile 2012 alle ore 17:30:40, Andre Fischer <af...@a-w-f.de> ha
scritto:
> Added English dictionary (plain en, no -US or other) for Italian UI.
> If (when) your factions come to an agreement, let me know.
The Italian users, who have answered to my question, prefer the light
solution (Italian + English only).
So you can keep things how they are now.
Anyway, it would be interesting to me to know why the "en" dictionary has
not a nation suffix even though it seems being an American English
dictionary only.
Regards,
--
Gianluca Turconi
Lettura gratuita o acquisto di libri e racconti di fantascienza,
fantasy, horror, noir, narrativa fantastica e tradizionale:
http://www.letturefantastiche.com/
Re: [RELEASE] Dictionary extensions
Posted by Andre Fischer <af...@a-w-f.de>.
On 05.04.2012 09:13, Gianluca Turconi wrote:
> In data 02 aprile 2012 alle ore 17:30:40, Andre Fischer <af...@a-w-f.de> ha
> scritto:
>
>> Added English dictionary (plain en, no -US or other) for Italian UI.
>> If (when) your factions come to an agreement, let me know.
>
> The Italian users, who have answered to my question, prefer the light
> solution (Italian + English only).
>
> So you can keep things how they are now.
OK, will do (doing nothing is what I do best).
>
> Anyway, it would be interesting to me to know why the "en" dictionary
> has not a nation suffix even though it seems being an American English
> dictionary only.
Yes, that is strange. I had assumed that it would provide a common
subset of the different "englishes".
-Andre
Re: [RELEASE] Dictionary extensions
Posted by Gianluca Turconi <gt...@letturefantastiche.com>.
In data 02 aprile 2012 alle ore 17:30:40, Andre Fischer <af...@a-w-f.de> ha
scritto:
> Added English dictionary (plain en, no -US or other) for Italian UI.
> If (when) your factions come to an agreement, let me know.
The Italian users, who have answered to my question, prefer the light
solution (Italian + English only).
So you can keep things how they are now.
Anyway, it would be interesting to me to know why the "en" dictionary has
not a nation suffix even though it seems being an American English
dictionary only.
Regards,
--
Gianluca Turconi
Lettura gratuita o acquisto di libri e racconti di fantascienza,
fantasy, horror, noir, narrativa fantastica e tradizionale:
http://www.letturefantastiche.com/
Re: [RELEASE] Dictionary extensions
Posted by Andre Fischer <af...@a-w-f.de>.
On 01.04.2012 12:06, Andrea Pescetti wrote:
> Gianluca Turconi wrote:
>> Andre Fischer:
>>> Ongoing: Italian team is working on the set of dictionaries to include
>>> for "it".
>>
>> If nobody objects to this, I'll be able to give an answer on next
>> Thursday.
>> Indeed, so far, there has been more feedback, split up in "factions",
>> than
>> what I expected. :-P
>
> Indeed, but since everybody seems to be fine with (at least) Italian and
> English, let's start by including those two, so that we can test that
> everything works. Then we might (or might not) add further dictionaries.
Added English dictionary (plain en, no -US or other) for Italian UI.
If (when) your factions come to an agreement, let me know.
-Andre
>
> Regards,
> Andrea.
Re: [RELEASE] Dictionary extensions
Posted by Gianluca Turconi <gt...@letturefantastiche.com>.
In data 01 aprile 2012 alle ore 12:06:50, Andrea Pescetti
<pe...@apache.org> ha scritto:
> Indeed, but since everybody seems to be fine with (at least) Italian and
> English, let's start by including those two, so that we can test that
> everything works. Then we might (or might not) add further dictionaries.
When is AOO 3.4 RC expected?
--
Gianluca Turconi
Lettura gratuita o acquisto di libri e racconti di fantascienza,
fantasy, horror, noir, narrativa fantastica e tradizionale:
http://www.letturefantastiche.com/
Re: [RELEASE] Dictionary extensions
Posted by Andrea Pescetti <pe...@apache.org>.
Gianluca Turconi wrote:
> Andre Fischer:
>> Ongoing: Italian team is working on the set of dictionaries to include
>> for "it".
>
> If nobody objects to this, I'll be able to give an answer on next Thursday.
> Indeed, so far, there has been more feedback, split up in "factions", than
> what I expected. :-P
Indeed, but since everybody seems to be fine with (at least) Italian and
English, let's start by including those two, so that we can test that
everything works. Then we might (or might not) add further dictionaries.
Regards,
Andrea.
Re: [RELEASE] Dictionary extensions
Posted by Gianluca Turconi <gt...@letturefantastiche.com>.
In data 29 marzo 2012 alle ore 15:49:28, Andre Fischer <af...@a-w-f.de> ha
scritto:
> Ongoing: Italian team is working on the set of dictionaries to include
> for "it".
If nobody objects to this, I'll be able to give an answer on next Thursday.
Indeed, so far, there has been more feedback, split up in "factions", than
what I expected. :-P
Regards,
--
Gianluca Turconi
Lettura gratuita o acquisto di libri e racconti di fantascienza,
fantasy, horror, noir, narrativa fantastica e tradizionale:
http://www.letturefantastiche.com/
Re: [RELEASE] Dictionary extensions
Posted by Andre Fischer <af...@a-w-f.de>.
Current Status: Bundled dictionaries for ui languages:
ui language dictionaries
--------------------------------------------------------
da da
de_AT de_AT
de_CH de_CH
de,de_DE de_DE, de_AT, de_CH, it, fr, en
en en, en_CA, en_US, en_AU, en_ZA, en_NZ
es es
fr fr
it it
nl en_US, fr, de_DE
no no
ro ro
ru ru, en_US, de
sl sl
Find details at [1]. If a language is not listed in the first column
then no dictionary will be bundled.
Ongoing: Italian team is working on the set of dictionaries to include
for "it".
_Call for Action:_ If your language is missing in this list, or you want
more dictionaries bundled for it then please reply to this thread. It
will not take much of your time.
Best regards,
Andre
[1]
https://cwiki.apache.org/confluence/display/OOOUSERS/Bundled+Writing+Aids