issue 79051

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|

issue 79051

Simon Brouwer
Hi all,

With respect to http://www.openoffice.org/issues/show_bug.cgi?id=79051 ,
It is unfortunate that the new, certified Dutch spell checking word list
is not included in OpenOffice.org 2.3.0. It can be downloaded via
DicOOo, but this is very time consuming when OOo is installed in an
organization. Also OOo in several Linux distributions apparently does
not even include the DicOOo wizard, and with the current security
(macro) restrictions it is not easy to get a standalone DicOOo to run.
I hope that the word list can be included in the next version.

Laci, are you still around?
//

--
Vriendelijke groet,
Simon Brouwer.

| http://nl.openoffice.org | http://www.opentaal.org |

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 79051

Laurent Godard-3
HI

  Also OOo in several Linux distributions apparently does
> not even include the DicOOo wizard, and with the current security
> (macro) restrictions it is not easy to get a standalone DicOOo to run.
> I hope that the word list can be included in the next version.
>

Using the legal menu
File > wizards > install new dictionaries, tou do not have macro
restriction problem

Laurent


--
Laurent Godard <[hidden email]> - Ingénierie OpenOffice.org -
http://www.indesko.com
Nuxeo Enterprise Content Management >> http://www.nuxeo.com -
http://www.nuxeo.org
Livre "Programmation OpenOffice.org", Eyrolles 2004-2006

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 79051

Simon Brouwer
Laurent Godard schreef:

> HI
>
>  Also OOo in several Linux distributions apparently does
>> not even include the DicOOo wizard, and with the current security
>> (macro) restrictions it is not easy to get a standalone DicOOo to run.
>> I hope that the word list can be included in the next version.
>>
>
> Using the legal menu
> File > wizards > install new dictionaries, tou do not have macro
> restriction problem
Sure, if you have this menu option. But it appears that the OOo flavour
bundled in some Linux distributions (at least OpenSuSE) doesn't include
the DicOOo wizard and therefore also not this menu option.

--
Vriendelijke groet,
Simon Brouwer.

| http://nl.openoffice.org | http://www.opentaal.org |

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 79051

Marcin Miłkowski
Simon Brouwer pisze:
> Sure, if you have this menu option. But it appears that the OOo flavour
> bundled in some Linux distributions (at least OpenSuSE) doesn't include
> the DicOOo wizard and therefore also not this menu option.

I've been reported that Fedora also hasn't bundled DicOOo into their OOo
version...

Couldn't we try to send some kind of official message from the
linguistic project to the package maintainers that DicOOo is an integral
part of the package and should always be bundled? That could solve a lot
of problems easily. Or at least we'd know why they didn't bundle DicOOo.

Regards,
Marcin

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 79051

Nicolas Mailhot

Le samedi 29 septembre 2007 à 12:56 +0200, Marcin Miłkowski a écrit :

> Couldn't we try to send some kind of official message from the
> linguistic project to the package maintainers that DicOOo is an integral
> part of the package and should always be bundled? That could solve a lot
> of problems easily. Or at least we'd know why they didn't bundle DicOOo.

I can explain it easily enough: we don't want private app-specific
installers.

1. We already have our own binary distribution pipeline we've worked
hard to push up to our demanding technical standards :
 * good networking support, including proxies, mirroring infrastructure,
support for local private mirrors, etc
 * good security (integration with system security rules, web of trust
with digitally signed updates)
 * etc

2. compared to our update system DicOOo is a joke, and BTW teaching
users to accept macro documents blindly is a security horror

3. users expect to find updates in the common update tools and complain
when they have to hunt and learn app-specific updaters

So instead of wasting energy pretending the linguistic project with its
few spell-checkers knows better the distribution job that distros which
have been at it for years and update systems from the kernel to the UI
theme, if OO.o could focus on getting its material in a format that
makes our distribution easy, we'd be grateful.

And we know you need some sort of crutch for windows users, since
Microsoft is not sharing its update pipes, but you know, we're *really*
not interested in sharing this crutch.

If I've failed to convey the deep loathing DicOOo triggers in
distribution people, I can try again.

[ And please don't even think of asking how DicOOo could be made more
palatable. It can't. Unless you want to give it the smarts to manage the
whole system, and it's good enough we can dump our system updater for
it. ]

--
Nicolas Mailhot

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: issue 79051

Marcin Miłkowski
Nicolas Mailhot pisze:

> So instead of wasting energy pretending the linguistic project with its
> few spell-checkers knows better the distribution job that distros which
> have been at it for years and update systems from the kernel to the UI
> theme, if OO.o could focus on getting its material in a format that
> makes our distribution easy, we'd be grateful.

Currently, the only option to install dictionaries that do not come with
OOo itself in distros that have such an exquisite system is to do it
manually. If you think this is better than using DicOOo, you should
probably consult your therapist.

As far as I know, nobody from this experienced group of distribution
gurus has ever contacted the linguistic project. We'd probably could
help you a lot but we never knew that you needed such help. You cannot
expect OOo NL project maintainers to inspect every possible Linux distro
on the planet and to try to fix the situation. I've seen distros that
simply install all possible dictionaries. And that's definitely a
performance hog for OOo.

Regards,
Marcin

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 79051

R.J. Baars
Marcin,

I am not mixing in this discussion, since it seems to be so fierce.

I would expect any distro, whick offers localisation, to be able to
distribute the right languages with OOO.
The main issue Simon adressed, is the right word list not being added
anyway, asking for it to be added next time.

Hope that doesn't get out of the picture discussing the 'desiredness' of
macros.

Ruud (reading along)


Marcin Miłkowski schreef:

> Nicolas Mailhot pisze:
>
>> So instead of wasting energy pretending the linguistic project with its
>> few spell-checkers knows better the distribution job that distros which
>> have been at it for years and update systems from the kernel to the UI
>> theme, if OO.o could focus on getting its material in a format that
>> makes our distribution easy, we'd be grateful.
>
> Currently, the only option to install dictionaries that do not come
> with OOo itself in distros that have such an exquisite system is to do
> it manually. If you think this is better than using DicOOo, you should
> probably consult your therapist.
>
> As far as I know, nobody from this experienced group of distribution
> gurus has ever contacted the linguistic project. We'd probably could
> help you a lot but we never knew that you needed such help. You cannot
> expect OOo NL project maintainers to inspect every possible Linux
> distro on the planet and to try to fix the situation. I've seen
> distros that simply install all possible dictionaries. And that's
> definitely a performance hog for OOo.
>
> Regards,
> Marcin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 79051

Nicolas Mailhot
In reply to this post by Marcin Miłkowski

Le samedi 29 septembre 2007 à 19:07 +0200, Marcin Miłkowski a écrit :

> Nicolas Mailhot pisze:
>
> > So instead of wasting energy pretending the linguistic project with its
> > few spell-checkers knows better the distribution job that distros which
> > have been at it for years and update systems from the kernel to the UI
> > theme, if OO.o could focus on getting its material in a format that
> > makes our distribution easy, we'd be grateful.
>
> Currently, the only option to install dictionaries that do not come with
> OOo itself
The set of dictionaries available on a Linux system is not what OO.o
chooses to bundle or not

> in distros that have such an exquisite system is to do it
> manually. If you think this is better than using DicOOo, you should
> probably consult your therapist.

And what you don't understand is a distribution an open system and the
solution to get something to users is to work with distributions not
workaround them.

> As far as I know, nobody from this experienced group of distribution
> gurus has ever contacted the linguistic project.

That's a funny argument, it seems I've made the effort to locate your
list not the reverse. And there are a lot *more* apps distributions are
interested in than distributions for apps to worry about.

> We'd probably could
> help you a lot but we never knew that you needed such help. You cannot
> expect OOo NL project maintainers to inspect every possible Linux distro
> on the planet and to try to fix the situation.

Read what I wrote again. We *don't* need help from you on the
distribution front. We *do* need you to help yourselves by making good
releases distributions can pick up and distribute.

> I've seen distros that
> simply install all possible dictionaries. And that's definitely a
> performance hog for OOo.

And that's an OO.o bug plain and simple so don't expect us to build our
system around your bugs. "Install everything" is a valid distribution
mode, other apps are smart enough to only load the resources they
actually use. We do allow language selection but at the system level,
because someone who wants russian support usually wants it in all its
apps, not just the office suite.

Anyway, to stop the mutual ranting, what distributions expect from a
component provider is :
A. an authoritative download source (ftp or http directory)
B. raw material in nice versionned archives
C. including licencing statements (in the archives), using well-known
licenses that don't need analysis
D. with if possible detached digital signatures or checksums to verify
we're distributing the right stuff
E. feedback channels (mailing list, irc channel, bug tracker)
F. update announce channels (RSS, announce list, whatever)
G. instructions to install your stuff via CLI scripts automatically
H. some roadmap info so we know how your release schedule fits in ours
F. all this on a nice easy-to-find webpage not something lost in a
website maze

To take a non-software example the DejaVu project (dejavu.sf.net) has
all this right and it got itself distributed by pretty much everyone in
a short span of time (one of the stragglers being OO.o BTW which still
has not realised Vera development stopped years ago)

OTOH lingucomponent makes it awfully hard to find raw dictionary
archives, check their version, their legal status, script their install,
etc. So distributions don't bother, or only for the main languages.

--
Nicolas Mailhot

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: issue 79051

Jancs
In reply to this post by Simon Brouwer
Citēju Simon Brouwer <[hidden email]>:

> With respect to http://www.openoffice.org/issues/show_bug.cgi?id=79051 ,
> It is unfortunate that the new, certified Dutch spell checking word list
> is not included in OpenOffice.org 2.3.0. It can be downloaded via

that's the same question discussed not once here, i think, and it is:

is it really useful to have __all__ dictionaries to packed within OO
installation package and, apparently, enabled through dictionaries.lst?

If such wish is still here, may be it is useful to make distro's with geographic
localization? For example - OO-North_American, OO_South_African, OO_Middle_East,
OO_Central_European etc?

Or, may be it is possible to add one more window for installator, where user
could enable/disable packed languages which are growing in larger and larger
number?

Janis
***

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 79051

Jancs
In reply to this post by Nicolas Mailhot
Citēju Nicolas Mailhot <[hidden email]>:

> > As far as I know, nobody from this experienced group of distribution
> > gurus has ever contacted the linguistic project.
>
> That's a funny argument, it seems I've made the effort to locate your
> list not the reverse. And there are a lot *more* apps distributions are
> interested in than distributions for apps to worry about.

to add some oil to the fire: some time ago i personally was contacted by the
Debian team with the question whether I agree to have included lv_LV in Debian
distro and what steps are necessary to get it installed.... and the module _is_
there for some years. Despite the fact i not announced it as final.

Janis
***

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 79051

Marcin Miłkowski
In reply to this post by Nicolas Mailhot
Nicolas Mailhot pisze:

> Le samedi 29 septembre 2007 à 19:07 +0200, Marcin Miłkowski a écrit :
>> Nicolas Mailhot pisze:
>>
>>> So instead of wasting energy pretending the linguistic project with its
>>> few spell-checkers knows better the distribution job that distros which
>>> have been at it for years and update systems from the kernel to the UI
>>> theme, if OO.o could focus on getting its material in a format that
>>> makes our distribution easy, we'd be grateful.
>> Currently, the only option to install dictionaries that do not come with
>> OOo itself
>
> The set of dictionaries available on a Linux system is not what OO.o
> chooses to bundle or not

You're wrong in some cases. Sometimes it is - distributors use OOo
sources to build their RPMs.

>
>> in distros that have such an exquisite system is to do it
>> manually. If you think this is better than using DicOOo, you should
>> probably consult your therapist.
>
> And what you don't understand is a distribution an open system and the
> solution to get something to users is to work with distributions not
> workaround them.

Mind you, I've been using Linux for ten years now and I really think
that all distribution systems need workarounds to get my work done. And
I've used anything from Slackware to Red Hat, to Debian, Mandriva,
Aurox, Suse, Ubuntu, PLD and probably some other stuff. So I don't
understand anyone claiming that this works. It works if you can compile
the system from the command line - but then you don't need all the smart
work that is supposed to be there ;)

> That's a funny argument, it seems I've made the effort to locate your
> list not the reverse. And there are a lot *more* apps distributions are
> interested in than distributions for apps to worry about.

OO.o is an international project so there are local distros we must
worry about in many countries.

>> I've seen distros that
>> simply install all possible dictionaries. And that's definitely a
>> performance hog for OOo.
>
> And that's an OO.o bug plain and simple so don't expect us to build our
> system around your bugs.

So don't expect users to use distributions that make their systems
useless in office work. Get real. It is the _user_ we need to worry
about and not some abstract theological discussions about fixing all
possible bugs. I cannot fix it myself and I'm not even sure if it still
is there. I only remember reading this as a tip in some OOo manual.

> Anyway, to stop the mutual ranting, what distributions expect from a
> component provider is :
> A. an authoritative download source (ftp or http directory)

There are OOo mirrors with most stuff that is put on the wiki.

> B. raw material in nice versionned archives

Not always feasible. Dictionary maintainers in some cases might be even
dead or we lost contact with them.

> C. including licencing statements (in the archives), using well-known
> licenses that don't need analysis

The bundled dicts are all LGPL. But we'd need to review that.

> D. with if possible detached digital signatures or checksums to verify
> we're distributing the right stuff

That's feasible.

> E. feedback channels (mailing list, irc channel, bug tracker)

Not feasible. You won't meet dictionary maintainers there if that's what
you mean. Otherwise, you can use this list.

> F. update announce channels (RSS, announce list, whatever)

That's possible.

> G. instructions to install your stuff via CLI scripts automatically

Probably feasible.

> H. some roadmap info so we know how your release schedule fits in ours

Dictionary releases are not centralized. There is no roadmap and there
cannot be. Nobody but the maintainer for the Malayalam can know when a
release is ready.

> F. all this on a nice easy-to-find webpage not something lost in a
> website maze

This is possible.

To sum up: in some cases, we have abandoned stuff we cannot update or
anything as maintainers are unknown or unreachable. So what you want is
something that cannot be even in the offing. I mean we accept open
source work but you cannot expect me, for example, to fix a Kashubian
dictionary. So we cannot simply do that for many languages. That's why
we need a system that allows you to accept the license (if it's not
LGPL), download the stuff, and install it. If you can do this for Adobe
Flash Player, you can do that for OOo dictionaries.

The nice thing is that in the near future, hunspell will replace myspell
in Mozilla projects. This means that Firefox dictionaries will be
exactly the same as in OOo. We could think of a common framework for
distribution. Anyway, you probably don't distribute Firefox spelling
dictionaries, do you? Let's reuse the solution as these are the same
files (in most cases, anyway, they are the same even now, the only
exceptions being those dictionaries that use advanced hunspell stuff).
As far as I remember Firefox people require me to click the website to
install an extension for every dictionary so that's not really bundled
in a distro, right?

> To take a non-software example the DejaVu project (dejavu.sf.net) has
> all this right and it got itself distributed by pretty much everyone in
> a short span of time (one of the stragglers being OO.o BTW which still
> has not realised Vera development stopped years ago)

Fine. But mind you, fonts are easier to maintain than dictionaries. In
most cases, you have more than one per language you can use the font in,
so you can simply select the right licenses, actively maintained ones
etc. It's not that simple in case of dictionaries. You cannot simply
pick the right ones if all you've got is some abandoned but decent stuff...

> OTOH lingucomponent makes it awfully hard to find raw dictionary
> archives, check their version, their legal status, script their install,
> etc. So distributions don't bother, or only for the main languages.

That's why we bother to make DicOOo work. And it works in most
situations. Firefox works the same way - as far as I know. So who's to
blame?

Regards,
Marcin

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 79051

Simon Brouwer
In reply to this post by Jancs
Jancs schreef:

> Citēju Simon Brouwer <[hidden email]>:
>
>  
>> With respect to http://www.openoffice.org/issues/show_bug.cgi?id=79051 ,
>> It is unfortunate that the new, certified Dutch spell checking word list
>> is not included in OpenOffice.org 2.3.0. It can be downloaded via
>>    
>
> that's the same question discussed not once here, i think, and it is:
>
> is it really useful to have __all__ dictionaries to packed within OO
> installation package and, apparently, enabled through dictionaries.lst?
>  
It is not the same question, because a Dutch spell checking word list
*is* included in OpenOffice.org 2.3.0. The problem is that it's an
obsolete one instead of the latest version.


I'm not saying that your question is not a valid one, though.

--
Vriendelijke groet,
Simon Brouwer.

| http://nl.openoffice.org | http://www.opentaal.org |

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 79051

Nicolas Mailhot
In reply to this post by Marcin Miłkowski
[for people interested in flames]


Le samedi 29 septembre 2007 à 21:18 +0200, Marcin Miłkowski a écrit :
> Nicolas Mailhot pisze:
> > Le samedi 29 septembre 2007 à 19:07 +0200, Marcin Miłkowski a écrit :

> > The set of dictionaries available on a Linux system is not what OO.o
> > chooses to bundle or not
>
> You're wrong in some cases. Sometimes it is - distributors use OOo
> sources to build their RPMs.

Then let me rephrase: distributions will make their own choice on what
they distribute or not, and it does not have to follow the OO.o choice
(indeed with other apps like Firefox 3 starting to use hunspell it most
probably won't).

So your horizon is not limited by OO.o releases

> >> in distros that have such an exquisite system is to do it
> >> manually. If you think this is better than using DicOOo, you should
> >> probably consult your therapist.
> >
> > And what you don't understand is a distribution an open system and the
> > solution to get something to users is to work with distributions not
> > workaround them.
>
> Mind you, I've been using Linux for ten years now and I really think
> that all distribution systems need workarounds to get my work done.
> [...] So I don't
> understand anyone claiming that this works.
It seems to work well enough to attract new users and the nature of
workarounds is to have them resorbed, not set in stone. But that needs
cooperation from upstream suppliers.

> > That's a funny argument, it seems I've made the effort to locate your
> > list not the reverse. And there are a lot *more* apps distributions are
> > interested in than distributions for apps to worry about.
>
> OO.o is an international project so there are local distros we must
> worry about in many countries.

The distribution that have been cited so far are hardly local and
besides you fix the situation for one it'll fixed itself for everyone.

If your argument is "I think I'm right, besides being told the contrary,
and I don't have to admit otherwise till every distribution on earth
tells me I'm wrong", that's childish and I could easily reverse the
argument.

> >> I've seen distros that
> >> simply install all possible dictionaries. And that's definitely a
> >> performance hog for OOo.
> >
> > And that's an OO.o bug plain and simple so don't expect us to build our
> > system around your bugs.
>
> So don't expect users to use distributions that make their systems
> useless in office work. Get real.

Get real yourself, the users are expecting stuff to be just installed
and just work, having them select at runtime separately from the rest of
the system languages is a gross workaround no user is fond of.

Besides you've snipped the part where I wrote the distro systems allow
selecting languages too.

>  I cannot fix it myself and I'm not even sure if it still
> is there.

So you're not even sure the workaround you're so keen on inflicting on
everyone is actually needed for something?

> > Anyway, to stop the mutual ranting, what distributions expect from a
> > component provider is :
> > A. an authoritative download source (ftp or http directory)
>
> There are OOo mirrors with most stuff that is put on the wiki.

And distributions have better things to do than hunt them down if you're
not interested enough to reference them.

> > B. raw material in nice versionned archives
>
> Not always feasible. Dictionary maintainers in some cases might be even
> dead or we lost contact with them.

And they'll sue you if you put their stuff in an archive with a number?
Get real.

Not that distributions can not fake numbers if needed, but that's one
more thing that's a PITA about lingucomponent and when you put all the
small annoyances together you understand why so few dictionaries are
available in-distro.

> > C. including licencing statements (in the archives), using well-known
> > licenses that don't need analysis
>
> The bundled dicts are all LGPL. But we'd need to review that.

Please do. Distributions care about not being sued for copyrighted work
misapropriation.

> > D. with if possible detached digital signatures or checksums to verify
> > we're distributing the right stuff
>
> That's feasible.
>
> > E. feedback channels (mailing list, irc channel, bug tracker)
>
> Not feasible. You won't meet dictionary maintainers there if that's what
> you mean.

So problems can not be reported, let alone fixed. No distribution will
be confortable with that.

> > F. update announce channels (RSS, announce list, whatever)
>
> That's possible.
>
> > G. instructions to install your stuff via CLI scripts automatically
>
> Probably feasible.
>
> > H. some roadmap info so we know how your release schedule fits in ours
>
> Dictionary releases are not centralized.
They are @ lingucomponent. Coordinating is your job, if you want to be
more than friendly wiki space.

> There is no roadmap and there
> cannot be. Nobody but the maintainer for the Malayalam can know when a
> release is ready.

But you can ask him and publish the info.

>
> > F. all this on a nice easy-to-find webpage not something lost in a
> > website maze
>
> This is possible.
>
> To sum up: in some cases, we have abandoned stuff we cannot update or
> anything as maintainers are unknown or unreachable. So what you want is
> something that cannot be even in the offing. I mean we accept open
> source work but you cannot expect me, for example, to fix a Kashubian
> dictionary. So we cannot simply do that for many languages.

> That's why
> we need a system that allows you to accept the license (if it's not
> LGPL), download the stuff, and install it.

That's why you *think* you need this system, none of your arguments are
even remotely compelling to distro ears, we've all heard them before and
they were as wrong then as they are today. For examples of how it ends,
see the AMD open driver statement or the SUN openjdk statement.

And they didn't use a half-hassed macroified system as distribution
method.

> If you can do this for Adobe
> Flash Player, you can do that for OOo dictionaries.

And that's the root of our contention. You consider this mode "natural",
our users don't (a large part won't install the flash player manually,
or hate doing it, especially on enterprise networks). As long as you
strive emulating Flash you'll find yourself moaning about lack of
distribution support.

> The nice thing is that in the near future, hunspell will replace myspell
> in Mozilla projects. This means that Firefox dictionaries will be
> exactly the same as in OOo.

This means the distros will have another hunspell dictionnary source
hopefully better organised than lingucomponent (not that we really want
to have two sources, but we'll gladly dump the less reasonable of them
if we have a choice)

>  We could think of a common framework for distribution.

Distribution is what distributions do and they started work on this
about a year ago, so you're late.

> Anyway, you probably don't distribute Firefox spelling
> dictionaries, do you?

We do for the major languages, We will do more with firefox3. We could
do them all if the dictionary hosting project was more helpful instead
of worrying about stuff we don't and won't use.

> Let's reuse the solution as these are the same
> files (in most cases, anyway, they are the same even now, the only
> exceptions being those dictionaries that use advanced hunspell stuff).
> As far as I remember Firefox people require me to click the website to
> install an extension for every dictionary so that's not really bundled
> in a distro, right?

The firefox system is a problem too BTW but at least being done by
browser people it has some security built-in and does not fall apart on
the first non-trivial network config it encounters.
With firefox3 modifications distributions asked for will permit
installation of firefox extensions through normal distro packages, so
the major distros will just distribute the most popular extensions
directly and users won't have to ressort to the firefox manual
installer.

> > To take a non-software example the DejaVu project (dejavu.sf.net) has
> > all this right and it got itself distributed by pretty much everyone in
> > a short span of time (one of the stragglers being OO.o BTW which still
> > has not realised Vera development stopped years ago)
>
> Fine. But mind you, fonts are easier to maintain than dictionaries.

You have no idea what you're talking about. Fonts cross language
boundaries, so you need to coordinate font designers from different
countries, they're all over the desktop, you have to get them working on
screens with different resolutions, in all the different font backends
application use, and users are extremely sensitive to pixel-level
defects.

> In
> most cases, you have more than one per language you can use the font in,
> so you can simply select the right licenses, actively maintained ones
> etc. It's not that simple in case of dictionaries. You cannot simply
> pick the right ones if all you've got is some abandoned but decent stuff...

Again this is wrong in particulars and in general. Fonts are harder than
dictionaries, distributions are a lot more afraid of font changes than
dictionary changes, and yet DejaVu got itself distributed because it did
what distributions like without dragging feet.

> > OTOH lingucomponent makes it awfully hard to find raw dictionary
> > archives, check their version, their legal status, script their install,
> > etc. So distributions don't bother, or only for the main languages.
>
> That's why we bother to make DicOOo work. And it works in most
> situations.

I'd replace "most" with "some"

> Firefox works the same way - as far as I know.

I've already explained distributions do not feel a lot better about
firefox extensions than DicOOo. But at least the firefox guys know how
to code a web client, they understand UI and security, their extensions
are hugely popular, they need to plug code not just dictionnary files,
so we hate their system less than yours.

You could take perl as another example. CPAN has its own direct
distribution method. But you know, 90% of linux users get their perl
through distro packages instead. And the CPAN guys mostly understand it,
they don't try to push everyone to their direct download system, they
help distributions distribute their stuff in deb/rpm/whatever form, and
everyone is happy.

> So who's to blame?

I'm not interested in blame though I know where it lies. I'm interested
in improving user systems. Someone asked what distribution though of the
problem. I've answered. If it was a rhetorical question and you've no
intention of actually listening to distributions I apologise for wasting
your time. Distributing is the heart of what distributions do and you
won't change their opinions on the subject. (And trying would require
contacting every distribution separately BTW).

--
Nicolas Mailhot

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: issue 79051

Nicolas Mailhot
In reply to this post by Marcin Miłkowski
[For people interested in fixing the dictionary situation under Linux –
in a separate message because most people will have ignored the flaming]

Here is my last-ditch effort to detail what distributions – every single
Linux/BSD distribution – expect of a project like yours. I defy you to
find a single distribution person that thinks otherwise. That's the
conventions distributions are geared around, that's what makes material
hit Linux user systems the fastest:

A. Create consolidated raw material release archives :
 1. regroup all the jumble of files on your wiki in a single archive
 2. if you have material with different stability level (stuff that can
be installed everywhere, alternative versions most people don't want,
stuff terminally broken you keep in the hope someone will fix it), split
this archive under those lines
 3. if you have stuff under different licenses, split again so every
archive has material under the same license. Put the authoritative
license text of each archive inside it in a COPYING file (and use
well-known licenses not something that needs a six-month trip to legal
to be checked)
 4. tag each archive with a release number, and increase the number next
time you change them (ex: foo-x.y.z.zip, bar-a.b.c.tar.bz2)

B. Publish them
 1. choose a reference long-term ftp directory or indexed http directory
 2. put world-readable archive files there
 3. add detached checksums/digital signatures so people can check
they've downloaded the right files
 4. do not remove old archives after an update. If you want to separate
the current release, use another directory with just this release in it,
but keep the directory with all past and present release files

C. Announce them
 1. have an RSS feed with new releases, send announcement messages on a
dedicated mailing list when you release a new file, put the info on the
center of your home page
 2. give people release highlights : what's new in the new release, why
people will want it, what change and may have broken since the last
release (having a changelog file in the release archives is nice too)

D. Coordinate
 1. Get your active dict authors agree on the next release date, and
publish this date so people can plan against it
 2. publish irc/ML/issue tracker channels where distro packagers can
reach you, and where they can direct users in case of
non-distribution-related problems
 3. relay this feedback to dict authors as necessary

And that's *all*. Nothing rocket science. A lot of it just boring
organisation you lack today and makes lingucomponent a PITA to work
with. Take care of this and distributions will take care of mirrors,
installer/updater UI, language selection, splitting of the archives to
reduce average downloads, license display, etc.

Alternatively you can keep on pushing Dictoo. You'll find no
distribution help on this front, and just waste the time of everyone
involved.

--
Nicolas Mailhot

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: issue 79051

Marcin Miłkowski
In reply to this post by Nicolas Mailhot
Nicolas Mailhot pisze:
> [for people interested in flames]

OK, let's stop the flame, right? Let me snip therefore most of our
sophisticated insults ;)

>>> A. an authoritative download source (ftp or http directory)
>> There are OOo mirrors with most stuff that is put on the wiki.
>
> And distributions have better things to do than hunt them down if you're
> not interested enough to reference them.

I don't know the mirror URLs but they are encoded in DicOOo, so they
exist. Let's first agree on what you need and then let's prepare the
details, right?

>>> B. raw material in nice versionned archives
>> Not always feasible. Dictionary maintainers in some cases might be even
>> dead or we lost contact with them.
>
> And they'll sue you if you put their stuff in an archive with a number?

OK, what I meant is that sometimes it's hard to track versions. But
again, we might use a date. So that's feasible.

>>> C. including licencing statements (in the archives), using well-known
>>> licenses that don't need analysis
>> The bundled dicts are all LGPL. But we'd need to review that.
>
> Please do. Distributions care about not being sued for copyrighted work
> misapropriation.

Fine. But what can we do about work that is incompatible with LGPL? Note
that hyphenation dictionaries are mostly on the standard LaTeX license
that is different from LGPL - they are based on TeX hyphenation
patterns. I tracked the origin of the Polish hyphenation patterns,
double-checked it, and confirmed it. But I was one of the few people
that actually were able to do so - sometimes it's actually very hard. I
can understand your dislike for hunting the licenses - I hate this as well!

>>> E. feedback channels (mailing list, irc channel, bug tracker)
>> Not feasible. You won't meet dictionary maintainers there if that's what
>> you mean.
>
> So problems can not be reported, let alone fixed. No distribution will
> be confortable with that.

I'm not comfortable with it either. But imposing a new system sometimes
makes little sense for those communities that have such a system (Polish
spelling dictionary has definitely one of the best processes and is
being very actively fixed in case any errors are found). We should
probably make a system for abandoned dictionaries - I filed some patches
for French dictionaries that make them better but there's nobody that
maintains them. So what we need is a dual system - reference to the
original bug-tracking system (if there's one), or use linguistic
project's issuezilla with special keywords. I can only say you're right
in claiming we need to fix it.

> They are @ lingucomponent. Coordinating is your job, if you want to be
> more than friendly wiki space.

Not really mine, I'm only an observer in this project, trying to help
sometimes ;)

>> That's why
>> we need a system that allows you to accept the license (if it's not
>> LGPL), download the stuff, and install it.
>
> That's why you *think* you need this system, none of your arguments are
> even remotely compelling to distro ears, we've all heard them before and
> they were as wrong then as they are today. For examples of how it ends,
> see the AMD open driver statement or the SUN openjdk statement.

But what can we do about dictionaries that are not really going to be on
LGPL for any reasons? Ignore them or enable users to download them? Note
  that for some languages we don't have a choice. See also the extension
idea below.

> And that's the root of our contention. You consider this mode "natural",
> our users don't (a large part won't install the flash player manually,
> or hate doing it, especially on enterprise networks). As long as you
> strive emulating Flash you'll find yourself moaning about lack of
> distribution support.

I don't find it natural but what can I or you do? I think we need
something better for users than making them use vi to edit the
configuration files, copy them to system-wide directories etc.

>> The nice thing is that in the near future, hunspell will replace myspell
>> in Mozilla projects. This means that Firefox dictionaries will be
>> exactly the same as in OOo.
>
> This means the distros will have another hunspell dictionnary source
> hopefully better organised than lingucomponent (not that we really want
> to have two sources, but we'll gladly dump the less reasonable of them
> if we have a choice)

I wouldn't be so sure about better organization there. They've only
realized that the main EN-US dictionary is not covered by MPL. That was
evident years ago.

> Distribution is what distributions do and they started work on this
> about a year ago, so you're late.

Am I? How can I install a Hungarian dictionary for OOo in openSuse with
Polish as a main language if I am not an admin? I cannot install such a
package even if I need it, and I'd have to contact the admins. That's
not a solution. That's as bad an idea as to have administrator account
in Windows for installing the dictionary for a single user account.

The idea right now is to enable installing dictionaries as extensions in
OOo, without DicOOo but directly via the web browser (or from the
downloaded files). The idea isn't yet implemented. But it cover the need
for dictionaries that won't change licenses (it's easy to review the
license before installing the extension in OOo right now).

>>> To take a non-software example the DejaVu project (dejavu.sf.net) has
>>> all this right and it got itself distributed by pretty much everyone in
>>> a short span of time (one of the stragglers being OO.o BTW which still
>>> has not realised Vera development stopped years ago)
>> Fine. But mind you, fonts are easier to maintain than dictionaries.
>
> You have no idea what you're talking about. Fonts cross language
> boundaries, so you need to coordinate font designers from different
> countries, they're all over the desktop, you have to get them working on
> screens with different resolutions, in all the different font backends
> application use, and users are extremely sensitive to pixel-level
> defects.

Maybe I have no idea, maybe I'm stupid but I've seen more fonts for
Kashubian (that uses complicated special diacritical characters) than
dictionaries. In this respect, you can choose better fonts etc., and
simply ignore the abandoned stuff. In case of dictionaries, you cannot.

> Again this is wrong in particulars and in general. Fonts are harder than
> dictionaries, distributions are a lot more afraid of font changes than
> dictionary changes, and yet DejaVu got itself distributed because it did
> what distributions like without dragging feet.

Maybe for some languages fonts are harder than dictionaries but for
Finnish, we haven't got a single good open source dictionary yet - it's
the language that is too hard for most spell-checking. But we have lots
of fonts that work with Finnish texts. This is what I mean.

> You could take perl as another example. CPAN has its own direct
> distribution method. But you know, 90% of linux users get their perl
> through distro packages instead. And the CPAN guys mostly understand it,
> they don't try to push everyone to their direct download system, they
> help distributions distribute their stuff in deb/rpm/whatever form, and
> everyone is happy.

OK, that's a good example. You've made your point.

Regards,
Marcin

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Finnish dictionaries (Was: issue 79051)

Harri Pitkänen
On Sunday 30 September 2007, Marcin Miłkowski wrote:
> Maybe for some languages fonts are harder than dictionaries but for
> Finnish, we haven't got a single good open source dictionary yet - it's
> the language that is too hard for most spell-checking.

Not related to the discussion you were having, but I have good news for you on
this particular matter. As of December 2006 there has been an open
source "dictionary" for Finnish that is of pretty good quality:

http://kaino.kotus.fi/sanat/nykysuomi/kotus-sanalista-v1.tar.gz

This contains 94 110 entries and has been released under the LGPL by the
Research Institute for the Languages of Finland. As far as I know (which is
not much), this is the same stuff they license commercially for language
technology companies, so having it available under the LGPL is something I am
quite happy about.

Unfortunately that is not a hunspell dictionary but a XML file with words and
inflection classes. This is not yet enough to build a spell checker. For this
purpose we are developing (under the GPL) software and dictionary database
that also takes advantage of the above mentioned data and our own additions:

http://voikko.sourceforge.net/

This software is already recognising over 99 % of words in typical Finnish
text and is starting to slowly replace the previous non-free spell checking
alternative for OOo. It is shipped in some Linux distros too, at least in
Debian, Ubuntu, and Mandriva.

Harri

[I also replied to the mail from Robert Ludvik where I explained how we are
handling user feedback when developing Voikko. But the mail seems to have
gone missing, maybe I sent it from a wrong address. I'll resend if it does
not appear here soon.]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 79051

Mathias Bauer
In reply to this post by Marcin Miłkowski
Hi Marcin,

Marcin Miłkowski wrote:

> Simon Brouwer pisze:
>> Sure, if you have this menu option. But it appears that the OOo flavour
>> bundled in some Linux distributions (at least OpenSuSE) doesn't include
>> the DicOOo wizard and therefore also not this menu option.
>
> I've been reported that Fedora also hasn't bundled DicOOo into their OOo
> version...
>
> Couldn't we try to send some kind of official message from the
> linguistic project to the package maintainers that DicOOo is an integral
> part of the package and should always be bundled? That could solve a lot
> of problems easily. Or at least we'd know why they didn't bundle DicOOo.

For OOo3.0 we want to get rid of DictOOo. We are currently enabling the
linguistic tools in OOo to be able to work with dictionaries installed
as extensions or anywhere(!) in the system. This works in the same way
as in case of templates: have a mergeable list of folders where OOo will
look for dictionaries, not a fixed list with only two predefined
entries. On the OOoCon I had some talks with Rene Engelhard and others
about this and I hope that we will have something that will please
everybody (if that is possible at all ;-)).

So in the worst case you have to stand the current situation for OOo2.4
the last time.

Ciao,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[hidden email]".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 79051

Mathias Bauer
In reply to this post by Marcin Miłkowski
Marcin Miłkowski wrote:

> So don't expect users to use distributions that make their systems
> useless in office work. Get real. It is the _user_ we need to worry
> about and not some abstract theological discussions about fixing all
> possible bugs. I cannot fix it myself and I'm not even sure if it still
> is there. I only remember reading this as a tip in some OOo manual.

The bug has been fixed some time ago - IIRC. Besides that I agree to
Nicolas that it's not the job of the distributors to care for bugs like
this one.

Besides that I think that it would be more fun to follow this thread if
the tone wasn't so rude (especially from Nicolas' side). I hope that our
plans about the new distribution options for dictionaries will be able
to stop this discussion.

Ciao,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[hidden email]".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Finnish dictionaries (Was: issue 79051)

Mathias Bauer
In reply to this post by Harri Pitkänen
Harri Pitkänen wrote:

> Not related to the discussion you were having, but I have good news for you on
> this particular matter. As of December 2006 there has been an open
> source "dictionary" for Finnish that is of pretty good quality:
>
> http://kaino.kotus.fi/sanat/nykysuomi/kotus-sanalista-v1.tar.gz
>
> This contains 94 110 entries and has been released under the LGPL by the
> Research Institute for the Languages of Finland. As far as I know (which is
> not much), this is the same stuff they license commercially for language
> technology companies, so having it available under the LGPL is something I am
> quite happy about.
>
> Unfortunately that is not a hunspell dictionary but a XML file with words and
> inflection classes. This is not yet enough to build a spell checker. For this
> purpose we are developing (under the GPL) software and dictionary database
> that also takes advantage of the above mentioned data and our own additions:
>
> http://voikko.sourceforge.net/

So are you planning to ask for replacing hunspell as OOo spell checker
by your new spell checker?

> This software is already recognising over 99 % of words in typical Finnish
> text and is starting to slowly replace the previous non-free spell checking
> alternative for OOo. It is shipped in some Linux distros too, at least in
> Debian, Ubuntu, and Mandriva.

What "non-free" spell checking alternative are you talking about? Sorry,
but I don't know the Finnish OOo version.

Ciao,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[hidden email]".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 79051

Mathias Bauer
In reply to this post by Jancs
Jancs wrote:

> Citēju Simon Brouwer <[hidden email]>:
>
>> With respect to http://www.openoffice.org/issues/show_bug.cgi?id=79051 ,
>> It is unfortunate that the new, certified Dutch spell checking word list
>> is not included in OpenOffice.org 2.3.0. It can be downloaded via
>
> that's the same question discussed not once here, i think, and it is:
>
> is it really useful to have __all__ dictionaries to packed within OO
> installation package and, apparently, enabled through dictionaries.lst?

You should be able to (de)select the (un)used ones in the installation.
For Linux distros that means you need separate packages for each and
every language. I also think that dictionaries shouldn't be bundled with
the UI localisation for the same language as people might want to write
text in different languages but keep their GUI to their own one.

These are points we need to address in our repackaging efforts.

Ciao,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[hidden email]".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

123