OpenOffice.org Dictionaries

[Phil Anderson]

Hi,

I'm not sure if this topic has been brought up before, but is there any
reason why the extra OpenOffice.org spelling and  hyphenation
dictionaries aren't included in Fedora Core or Fedora.us?

Unless anyone has any reason not to, I am going to package them.  I'll
put each language in it's own RPM, containing both the spelling and the
hyphenation dictionaries.

e.g.
openoffice.org-dicts-en_CS.20040410-0.fdr.1.1.noarch.rpm
openoffice.org-dicts-en_AU.20040410-0.fdr.1.1.noarch.rpm

Do you think I should use one big source RPM for all the languages?  The
down side of this is that the dictionaries are updated in an ad-hoc
manner, so you would have to rebuild the whole lot if you only wanted to
update one language.

For your information, the dictionaries are at:
http://lingucomponent.openoffice.org/spell_dic.html
http://lingucomponent.openoffice.org/hyph_dic.html

-- 
Phil Anderson <phil(a)phil-anderson.com&gt;

[Rex Dieter]

Phil Anderson wrote:
>  Hi,
>  
>  I'm not sure if this topic has been brought up before, but is there any
>  reason why the extra OpenOffice.org spelling and  hyphenation
>  dictionaries aren't included in Fedora Core or Fedora.us? 
Apparently, the more dictionaries installed, performance degrades. 
Other than that, it's possibly because it's more work or little 
demand... (-:

>  Do you think I should use one big source RPM for all the languages? 
Separated makes the most sense to me.

-- Rex

[Dan Williams]

Hi,

The performance degredation is not necessarily for each additional 
dictionary installed, but for each additional dictionary _enabled_.  We 
could install all the dictionaries by default, but people seem to always 
click the "Check spelling in all languages" button, and _that_ is where 
the performance degrades, and horribly.  You really can't blame OOo here 
since its attempting to check spelling with like 30 dictionaries and 
hyphenators.  People do this because they are lazy and don't want to 
actually find and enable the dictionaries they need (which is probably the 
fault of OOo's interface).

I suppose a good solution to this would be to remove that checkbox from 
the dialog.

Dan

On Fri, 9 Apr 2004, Rex Dieter wrote:

>  Phil Anderson wrote:
>  > Hi,
>  > 
>  > I'm not sure if this topic has been brought up before, but is there any
>  > reason why the extra OpenOffice.org spelling and  hyphenation
>  > dictionaries aren't included in Fedora Core or Fedora.us?
>  
>  Apparently, the more dictionaries installed, performance degrades. 
>  Other than that, it's possibly because it's more work or little 
>  demand... (-:
>  
>  > Do you think I should use one big source RPM for all the languages? 
>  
>  Separated makes the most sense to me.
>  
>  -- Rex
>  
>  
>  -- 
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-devel-list
>

[M. Fioretti]

On Sat, Apr 10, 2004 11:00:48 AM +1000, Phil Anderson (phil(a)phil-anderson.com) wrote:
>  
>  Do you think I should use one big source RPM for all the languages?  
Please no, keep them separated. In addition to the reason you mention,
saving space on disk is never a bad idea.

Ciao,
	Marco Fioretti

-- 
Marco Fioretti                 m.fioretti, at the server inwind.it
Red Hat for low memory         http://www.rule-project.org/en/

Furious activity is no substitute for understanding. --  H.H. Williams

[Razvan Corneliu C.R. "d3vi1" VILT]

On Sat, 2004-04-10 at 11:30 +0200, M. Fioretti wrote:

>  On Sat, Apr 10, 2004 11:00:48 AM +1000, Phil Anderson
> (phil(a)phil-anderson.com) wrote:
>  > 
>  > Do you think I should use one big source RPM for all the languages? 
>
>  Please no, keep them separated. In addition to the reason you mention,
>  saving space on disk is never a bad idea.
>   
He meant Source RPM as in .src.rpm or .srpm
Just like for other packages the binaries can be split. kernel is also
only one __SOURCE__ package but multiple binaries
(i386/i586/i686/docs/source)

Haveing a single source package is a better sollution because you can
have a consistent way of patching things, and only one spec file.

My vote goes for "1 source package" and "1 binary package for each
language".

[M. Fioretti]

On Sat, Apr 10, 2004 15:11:49 PM +0300, Razvan Corneliu C.R. d3vi1 VILT
(razvan.vilt(a)linux360.ro) wrote:
>  > Please no, keep them separated. In addition to the reason you
> mention,
>  > saving space on disk is never a bad idea.
>  > 
>  He meant Source RPM as in .src.rpm or .srpm
>  Just like for other packages the binaries can be split. kernel is also
>  only one __SOURCE__ package but multiple binaries
>  (i386/i586/i686/docs/source)
>  
>  Haveing a single source package is a better sollution because you can
>  have a consistent way of patching things, and only one spec file.
>  
>  My vote goes for "1 source package" and "1 binary package for each
>  language". 
Agreed 100%. I was referring only to .rpm for end users interested in
only one language.

Ciao,
	Marco Fioretti

-- 
Marco Fioretti                 m.fioretti, at the server inwind.it
Red Hat for low memory         http://www.rule-project.org/en/

Preserve the old, but know the new.

[Nicolas Mailhot]

Le sam, 10/04/2004 à 15:11 +0300, Razvan Corneliu C.R. "d3vi1" VILT a
écrit :

>  On Sat, 2004-04-10 at 11:30 +0200, M. Fioretti wrote:
>  
>  > On Sat, Apr 10, 2004 11:00:48 AM +1000, Phil Anderson (phil(a)phil-anderson.com)
> wrote:
>  > > 
>  > > Do you think I should use one big source RPM for all the languages? 
>  >
>  > Please no, keep them separated. In addition to the reason you mention,
>  > saving space on disk is never a bad idea.
>  > 
>  He meant Source RPM as in .src.rpm or .srpm
>  Just like for other packages the binaries can be split. kernel is also
>  only one __SOURCE__ package but multiple binaries
>  (i386/i586/i686/docs/source)
>  
>  Haveing a single source package is a better sollution because you can
>  have a consistent way of patching things, and only one spec file.
>  
>  My vote goes for "1 source package" and "1 binary package for each
>  language". 
If you take a look on the release dates on the oo.o site you'll see
dictionnaries are not synched with oo.o releases (in fact some of them
stay the same for years).

So separate SRPMS is the way to go IMHO (which might require some logic
in oo.o to get stuff in an unversionned dir, much like the plugins dir
for moz)

Cheers,

-- 
Nicolas Mailhot

[Razvan Corneliu C.R. "d3vi1" VILT]

On Sat, 2004-04-10 at 15:37 +0200, Nicolas Mailhot wrote:


>  Le sam, 10/04/2004 à 15:11 +0300, j'ai écrit :
>  
>  > On Sat, 2004-04-10 at 11:30 +0200, M. Fioretti wrote:
>  > 
>  > > On Sat, Apr 10, 2004 11:00:48 AM +1000, Phil Anderson (phil(a)phil-anderson.com)
> wrote:
>  > > > 
>  > > > Do you think I should use one big source RPM for all the languages? 
>  > >
>  > > Please no, keep them separated. In addition to the reason you mention,
>  > > saving space on disk is never a bad idea.
>  > > 
>  > He meant Source RPM as in .src.rpm or .srpm
>  > Just like for other packages the binaries can be split. kernel is also
>  > only one __SOURCE__ package but multiple binaries
>  > (i386/i586/i686/docs/source)
>  > 
>  > Haveing a single source package is a better sollution because you can
>  > have a consistent way of patching things, and only one spec file.
>  > 
>  > My vote goes for "1 source package" and "1 binary package for each
>  > language".
>  
>  If you take a look on the release dates on the oo.o site you'll see
>  dictionnaries are not synched with oo.o releases (in fact some of them
>  stay the same for years).
>  
>  So separate SRPMS is the way to go IMHO (which might require some logic
>  in oo.o to get stuff in an unversionned dir, much like the plugins dir
>  for moz)
>  
>  Cheers, 

I never suggested the same .src.rpm with oo.o. I just said that there
should be only one openoffice.org-dicts-$ver.src.rpm and multiple binary
rpms: openoffice.org-dicts-$lang-$ver.noarch.rpm. I belive that kde does
the same with kde-i18n, and over there, some translations are better,
others worst.

Cheers
Beers :-P

[Thorsten Tasch]

>  I'm not sure if this topic has been brought up before, but is
> there any
>  reason why the extra OpenOffice.org spelling and  hyphenation
>  dictionaries aren't included in Fedora Core or Fedora.us? 
Can you also package the various thesauruses which are available for
OpenOffice.org? Maybe you could also add some templates for
OpenOffice.org (at least the German language team has a small package).

Comments? (OpenOffice.org Dictionaries)

[Dan Williams]

Hi,

There is also the DicOOo.sxw automated dictionary/hyphenator/thesaurus
installation program, much like an automated update program.  It is a
Writer document that contains macros that automatically retrieve the
i18n component lists and download and install them for you.  It works
rather well.

The problem with separate language packs is when do you install them?
They could potentially be added to the comps files so that each
additional OOo language would only be installed if you selected that
language in Anaconda.  However, what do you do after the fact?  How
would they be distributed?  How would you notify users of the additional
language packs' existence?

It may well be from a distribution standpoint that DicOOo is the best
way to go since it empowers users to install only what they need, and
makes it easily available.  However, it has a few drawbacks (none fatal
I think): its basically a big macro, some people are uneasy about that,
and there is also no guarantee how long the information it uses will be
up online.  However, it does have an active community around it, it _is_
being shipped with the official OpenOffice.org, and is generally well
localized.

There will probably always be a place for standalone dictionary/
hyphenator/thesaurus packs though.

Looking forward as the Fedora Core / Red Hat maintainer of the OOo
packages, what do people think I should do?

Dan

On Sat, 2004-04-10 at 11:00 +1000, Phil Anderson wrote:
>  Hi,
>  
>  I'm not sure if this topic has been brought up before, but is there any
>  reason why the extra OpenOffice.org spelling and  hyphenation
>  dictionaries aren't included in Fedora Core or Fedora.us?
>  
>  Unless anyone has any reason not to, I am going to package them.  I'll
>  put each language in it's own RPM, containing both the spelling and the
>  hyphenation dictionaries.
>  
>  e.g.
>  openoffice.org-dicts-en_CS.20040410-0.fdr.1.1.noarch.rpm
>  openoffice.org-dicts-en_AU.20040410-0.fdr.1.1.noarch.rpm
>  
>  Do you think I should use one big source RPM for all the languages?  The
>  down side of this is that the dictionaries are updated in an ad-hoc
>  manner, so you would have to rebuild the whole lot if you only wanted to
>  update one language.
>  
>  For your information, the dictionaries are at:
>  http://lingucomponent.openoffice.org/spell_dic.html
>  http://lingucomponent.openoffice.org/hyph_dic.html
>  
>  -- 
>  Phil Anderson <phil(a)phil-anderson.com&gt;
>  
>  
>  -- 
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-devel-list

Comments? (OpenOffice.org Dictionaries)

[Miloslav Trmač]

Hello,
On Mon, Apr 12, 2004 at 10:31:55AM -0400, Dan Williams wrote:
>  The problem with separate language packs is when do you install
> them?
>  They could potentially be added to the comps files so that each
>  additional OOo language would only be installed if you selected that
>  language in Anaconda.  However, what do you do after the fact? 
What more needs to
be done? Does using the installed language packs
require additional manual intervention?

>  How
>  would they be distributed?  How would you notify users of the additional
>  language packs' existence? 
Same as you distribute/notify about any other
package - they either are
on the Core CDs, or in a (presumably well-known) repository.

>  It may well be from a distribution standpoint that DicOOo is the
> best
>  way to go since it empowers users to install only what they need, and
>  makes it easily available.  However, it has a few drawbacks (none fatal
>  I think): its basically a big macro, some people are uneasy about that,
>  and there is also no guarantee how long the information it uses will be
>  up online. 
* It requires additional manual action after installation (consider
kickstart)
  Post-install scripts would probably not be able to use DicOOo, so they would
  have to mostly reimplement the language RPMs
* It does not collaborate with the RPM package database
* <paranoid>Users might download a malicious "dicOOo" script from
something
  that looks like a legitimate openoffice.org mirror</paranoid>

>  Looking forward as the Fedora Core / Red Hat maintainer of the OOo
>  packages, what do people think I should do? 
Given all the above (and the fact that
Czech was included in the main
package in previous releases :) I'd prefer language packages (we do have
about 400 MB left on the fourth CD, after all), but I understand
that's additional work to be done.

While I don't have the disk space to build the main OO.o package,
I'd be glad to help with building the l10n packs.
	Mirek

Comments? (OpenOffice.org Dictionaries)

[Dan Williams]

Hi,

I guess the disadvantage of individual language packs is that users have
to go off and find them and install them.  Consider:

o  Additional logic applied to Anaconda to install only the languages
necessary for the user (not sure, will ask Jeremy how much work it will
be)

o  Must be _root_ to install these language packs.  With DicOOo you
don't have to be.

o  If the installation is not done at system install time, the user
still has to manually install language packs, as with DicOOo.

I'm not giving a +1 to DicOOo, its just something to think about.  I'm
not sure everybody has the huge amounts of space on CDs to be able to
package all the language packs that would be created (probably 25 or
30).  Remember, the language packs would include the following:

dictionary
hyphenator
thesaurus
localized *.res files
localized Help files

Each would probably be anywhere from 5MB to 30MB depending on the
coverage...

Dan

On Mon, 2004-04-12 at 17:15 +0200, Miloslav Trmac wrote:
>  Hello,
>  On Mon, Apr 12, 2004 at 10:31:55AM -0400, Dan Williams wrote:
>  > The problem with separate language packs is when do you install them?
>  > They could potentially be added to the comps files so that each
>  > additional OOo language would only be installed if you selected that
>  > language in Anaconda.  However, what do you do after the fact?
>  What more needs to be done? Does using the installed language packs
>  require additional manual intervention?
>  
>  > How
>  > would they be distributed?  How would you notify users of the additional
>  > language packs' existence?
>  Same as you distribute/notify about any other package - they either are
>  on the Core CDs, or in a (presumably well-known) repository.
>  
>  > It may well be from a distribution standpoint that DicOOo is the best
>  > way to go since it empowers users to install only what they need, and
>  > makes it easily available.  However, it has a few drawbacks (none fatal
>  > I think): its basically a big macro, some people are uneasy about that,
>  > and there is also no guarantee how long the information it uses will be
>  > up online.
>  * It requires additional manual action after installation (consider kickstart)
>    Post-install scripts would probably not be able to use DicOOo, so they would
>    have to mostly reimplement the language RPMs
>  * It does not collaborate with the RPM package database
>  * <paranoid>Users might download a malicious "dicOOo" script from
> something
>    that looks like a legitimate openoffice.org mirror</paranoid>
>  
>  > Looking forward as the Fedora Core / Red Hat maintainer of the OOo
>  > packages, what do people think I should do?
>  Given all the above (and the fact that Czech was included in the main
>  package in previous releases :) I'd prefer language packages (we do have
>  about 400 MB left on the fourth CD, after all), but I understand
>  that's additional work to be done.
>  
>  While I don't have the disk space to build the main OO.o package,
>  I'd be glad to help with building the l10n packs.
>  	Mirek
>  
>  
>  -- 
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-devel-list

Comments? (OpenOffice.org Dictionaries)

[Miloslav Trmač]

On Mon, Apr 12, 2004 at 12:41:41PM -0400, Dan Williams wrote:
>  I guess the disadvantage of individual language packs is that users
> have
>  to go off and find them and install them.  Consider: 
It might be easier to search
for RPMs than for an additional,
application-specific mechanism.

>  o  Additional logic applied to Anaconda to install only the
> languages
>  necessary for the user (not sure, will ask Jeremy how much work it will
>  be) 
This is already done for kde-i18n-* and seems to work fine.

>  o  Must be _root_ to install these language packs.  With DicOOo you
>  don't have to be. 
You don't lose the ability to install them with DicOOo,
though.

Basically, this is exactly the same argument as "do we include a package
in the distribution or do we let the users install it themselves?".

I obviously can't force an answer on you, but I can help if you happen
to agree with me :)
	Mirek

Comments? (OpenOffice.org Dictionaries)

[Jeremy Katz]

On Mon, 2004-04-12 at 18:46 +0200, Miloslav Trmac wrote:
>  On Mon, Apr 12, 2004 at 12:41:41PM -0400, Dan Williams wrote:
>  > o  Additional logic applied to Anaconda to install only the languages
>  > necessary for the user (not sure, will ask Jeremy how much work it will
>  > be)
>  This is already done for kde-i18n-* and seems to work fine. 
There are actually a number of cases where this breaks in weird ways.  

Jeremy

Comments? (OpenOffice.org Dictionaries)

[Bill Nottingham]

Miloslav Trmac (mitr(a)volny.cz) said: 
>  > o  Additional logic applied to Anaconda to install only the
> languages
>  > necessary for the user (not sure, will ask Jeremy how much work it will
>  > be)
>  This is already done for kde-i18n-* and seems to work fine. 
No, it doesn't.

a) it's not necessarily in sync with each app
b) you get translations for everything, instead of just translations
   for the apps you have installed
c) to get new translations for one app, you have to rebuild a 150MB
   source rpm
d) you have to have special logic in install programs just to get
   translations

To elaborate on 'd', if I, as a user, do 'up2date -i wibble', you'd
have to hardcode some logic that if LANG=de_DE.UTF-8, you need to also
install 'wobble-i18n-German'. That's a PITA to maintain.

In short, I feel it's the absolute wrong approach.

Bill

Comments? (OpenOffice.org Dictionaries)

[Michael A. Peters]

On Mon, 2004-04-12 at 09:41, Dan Williams wrote:
>  Hi,
>  
>  I guess the disadvantage of individual language packs is that users have
>  to go off and find them and install them.  Consider:
>  
>  o  Additional logic applied to Anaconda to install only the languages
>  necessary for the user (not sure, will ask Jeremy how much work it will
>  be) 
%lang in the rpm should take of that no problem

>  
>  o  Must be _root_ to install these language packs.  With DicOOo you
>  don't have to be. 
I think a change needs to made to package installation in general.
I think only the _base core_ should be installed by root.

Then something like /software/{bin,include,lib,etc,var,yada} that is
writable by user software - a user that doesn't have a login, but has a
group that the sysadmin can add users to.

A wrapper for rpm is installed that has suid bit set to user software -
but only executable for users in the group software. Thus someone in the
group software can install those rpm's and they will install as if the
user software installed them. But the users in the group software do not
themselves actually have write access to the /software directory
structure. Strict requirement of PGP sig policy can be enforced to
prevent a hijacked account who is in group software from installing a
trojan rpm that ends up in other people's path.

This would allow the _base_ OS to be quite small - as most of the
applications could be separated from the _base_ install.

It would also mean that the need to become root is greatly reduced -
updating the system won't need to be done as root except for the few
packages that really can't be installed in /software (services with init
scripts, stuff like that) and that would be safer, because the
connection to the update server wouldn't be done as root (something I
don't like about up2date and yum) and the %pre/%post scripts wouldn't
need to be run as root.

I'm working on a write up of my idea.

The only thing that might be an issue is ldconfig - but I think properly
setting the LDFLAGS at configure time should eliminate that issue (as in
- LDFLAGS="-L/software/lib/qt-1.3"; export LDFLAGS; %configure
--with-qt=/software/lib/qt-1.3 or whatever)

I have to do some testing of that though.

>  
>  o  If the installation is not done at system install time, the user
>  still has to manually install language packs, as with DicOOo.
>   
Not if a single rpm is provided that has proper %lang flags - and the
installer only installs the requested %lang files.
-- 
Cheap Linux CD's - http://mpeters.us/linux/

Comments? (OpenOffice.org Dictionaries)

[Jeremy Katz]

On Mon, 2004-04-12 at 10:24 -0700, Michael A. Peters wrote:
>  On Mon, 2004-04-12 at 09:41, Dan Williams wrote:
>  > I guess the disadvantage of individual language packs is that users have
>  > to go off and find them and install them.  Consider:
>  > 
>  > o  Additional logic applied to Anaconda to install only the languages
>  > necessary for the user (not sure, will ask Jeremy how much work it will
>  > be)
>  
>  %lang in the rpm should take of that no problem 
That does nothing for a few reasons..
1) Anaconda doesn't set %_install_langs anymore.  It caused massive
problems for anyone who wanted to actually use some language after an
initial install that wasn't originally selected.  The answer had to
basically be "reinstall completely"
2) Even if it was effective, would you then install all of the unused
packages (ie ooo-german) and then have lots of useless packages
installed (though without files).  This would be very strange to me :-)

Jeremy

Comments? (OpenOffice.org Dictionaries)

[Thorsten Leemhuis]

Am Mo, den 12.04.2004 schrieb Miloslav Trmac um 17:15:
>  Hello,
>  On Mon, Apr 12, 2004 at 10:31:55AM -0400, Dan Williams wrote: 
[...]
>  
>  > It may well be from a distribution standpoint that DicOOo is the best
>  > way to go since it empowers users to install only what they need, and
>  > makes it easily available.  However, it has a few drawbacks (none fatal
>  > I think): its basically a big macro, some people are uneasy about that,
>  > and there is also no guarantee how long the information it uses will be
>  > up online.
>  * It requires additional manual action after installation (consider kickstart)
>    Post-install scripts would probably not be able to use DicOOo, so they would
>    have to mostly reimplement the language RPMs
>  * It does not collaborate with the RPM package database
>  * <paranoid>Users might download a malicious "dicOOo" script from
> something
>    that looks like a legitimate openoffice.org mirror</paranoid> 
++ on these points. I used DicOOo two or there times and was not very
comfortable with it... 


>  > Looking forward as the Fedora Core / Red Hat maintainer of the
> OOo
>  > packages, what do people think I should do?
>  Given all the above (and the fact that Czech was included in the main
>  package in previous releases :) I'd prefer language packages (we do have
>  about 400 MB left on the fourth CD, after all), but I understand
>  that's additional work to be done. 
What about delivering the "widespread" languages as rpm with Fedora Core
and put the other in fedora-extras?

CU
thl

Comments? (OpenOffice.org Dictionaries)

[Dan Williams]

An argument against DicOOo is that its not "package managed files"
either...  you can't rpm -e a package and get rid of them.

An argument against individual i18n files is that if you have an errata
for OpenOffice.org, the you have to do the QA process and errata _every_
single one of the i18n packages too, which is more administrative
overhead.

Also, I hear that the KDE i18n stuff is special-cased inside of
Anaconda, the same would have to be done for OOo if that is true (jeremy
is at lunch right now).

However, as the # of languages for OOo grows, I doubt people would want
to download a monolithic package of all OOo langs since that would be
very large.

In the end, it _does_ look like individual i18n files are the best way
to go, but only since the package is so large...

Dan

Comments? (OpenOffice.org Dictionaries)

[Miloslav Trmač]

On Mon, Apr 12, 2004 at 01:08:14PM -0400, Dan Williams wrote:
>  An argument against individual i18n files is that if you have an
> errata
>  for OpenOffice.org, the you have to do the QA process and errata _every_
>  single one of the i18n packages too, which is more administrative
>  overhead. 
Why push an errata for dictionaries? Assuming the file format does not
 change and the upgrade doesn't change dictionary.lst, AFAICS they can
happily stay in /usr/lib/openoffice/share/dict/ooo (although I admit I
haven't looked at hyphenation and thesaurus).

This might be more difficult for grammar checkers, though.

>  Also, I hear that the KDE i18n stuff is special-cased inside of
>  Anaconda, the same would have to be done for OOo if that is true (jeremy
>  is at lunch right now). 
A quick grep does not confirm that.
	Mirek

Comments? (OpenOffice.org Dictionaries)

[Dan Williams]

Hi,

On Mon, 2004-04-12 at 19:17 +0200, Miloslav Trmac wrote:
>  Why push an errata for dictionaries? Assuming the file format does
> not
>   change and the upgrade doesn't change dictionary.lst, AFAICS they can
>  happily stay in /usr/lib/openoffice/share/dict/ooo (although I admit I
>  haven't looked at hyphenation and thesaurus). 
Because the Openoffice.org package changed.  Since everything for a
language is bundled together, you need to rev each of the language
packages when you rev the openoffice.org package.  The dictionaries are
not the _only_ part of the language pack.

>  > Also, I hear that the KDE i18n stuff is special-cased inside of
>  > Anaconda, the same would have to be done for OOo if that is true (jeremy
>  > is at lunch right now).
>  A quick grep does not confirm that. 
Jeremy confirms that anaconda does special-case individual language pack
stuff if only just for KDE at this time.

Dan

Comments? (OpenOffice.org Dictionaries)

[Nicolas Mailhot]

Le lun, 12/04/2004 à 14:09 -0400, Dan Williams a écrit :

>  Hi,
>  
>  On Mon, 2004-04-12 at 19:17 +0200, Miloslav Trmac wrote:
>  > Why push an errata for dictionaries? Assuming the file format does not
>  >  change and the upgrade doesn't change dictionary.lst, AFAICS they can
>  > happily stay in /usr/lib/openoffice/share/dict/ooo (although I admit I
>  > haven't looked at hyphenation and thesaurus).
>  
>  Because the Openoffice.org package changed.  Since everything for a
>  language is bundled together, you need to rev each of the language
>  packages when you rev the openoffice.org package.  The dictionaries are
>  not the _only_ part of the language pack. 
But they are the part that does not scale well and needs to be
separated. UI localisation can (and should) be bundled with the core oo
package.

It's not just about having the UI and spellchecking match the user
primary langage. It's about being able to spellcheck a secundary langage
too. This is where MS office is terrible BTW - locating a version in a
given langage is easy, locating one that can spellcheck another one is
almost impossible (french office with russian spelling, portuguese one
with greek/arab spellchecker and so on).

There is actually quite a lot of value in independent
spelling/hyphenation/etc bundles. People can live (badly) with an UI in
a foreign langage, they can not perfectly spellcheck their own langage
without help (let alone a foreign langage).

Cheers,

-- 
Nicolas Mailhot

Comments? (OpenOffice.org Dictionaries)

[Dan Williams]

When you split off the dict/hyph/thes files from the resource & help
localizations, there really isn't all that much point to bundling them
as separate packages.  While some dictionaries are large, the dict/hyph/
thes files are much smaller than the resource & help localizations.

IMHO, there's no point to separate dict/hyph/thes files if you're going
to split them out; you might as well add them to the monolithic i18n
RPM.  It simply takes more time to maintain and more headache for
errata.

I agree that its good to be able to spellcheck in a couple languages, I
patched a Language dropdown into the OOo toolbar to help that out
tremendously... (#i23518#)  However, I'm in favor of a monolithic i18n
RPM over only dict/hyph/thes files as separate RPMs.

Dan

On Mon, 2004-04-12 at 20:28 +0200, Nicolas Mailhot wrote:
>  Le lun, 12/04/2004 à 14:09 -0400, Dan Williams a écrit :
>  
>  > Hi,
>  > 
>  > On Mon, 2004-04-12 at 19:17 +0200, Miloslav Trmac wrote:
>  > > Why push an errata for dictionaries? Assuming the file format does not
>  > >  change and the upgrade doesn't change dictionary.lst, AFAICS they can
>  > > happily stay in /usr/lib/openoffice/share/dict/ooo (although I admit I
>  > > haven't looked at hyphenation and thesaurus).
>  > 
>  > Because the Openoffice.org package changed.  Since everything for a
>  > language is bundled together, you need to rev each of the language
>  > packages when you rev the openoffice.org package.  The dictionaries are
>  > not the _only_ part of the language pack.
>  
>  But they are the part that does not scale well and needs to be
>  separated. UI localisation can (and should) be bundled with the core oo
>  package.
>  
>  It's not just about having the UI and spellchecking match the user
>  primary langage. It's about being able to spellcheck a secundary langage
>  too. This is where MS office is terrible BTW - locating a version in a
>  given langage is easy, locating one that can spellcheck another one is
>  almost impossible (french office with russian spelling, portuguese one
>  with greek/arab spellchecker and so on).
>  
>  There is actually quite a lot of value in independent
>  spelling/hyphenation/etc bundles. People can live (badly) with an UI in
>  a foreign langage, they can not perfectly spellcheck their own langage
>  without help (let alone a foreign langage).
>  
>  Cheers,
>  
>  -- 
>  Nicolas Mailhot
>  
>  -- 
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-devel-list

Comments? (OpenOffice.org Dictionaries)

[Nicolas Mailhot]

>  On Mon, Apr 12, 2004 at 01:08:14PM -0400, Dan Williams wrote:
>  > An argument against individual i18n files is that if you have an errata
>  > for OpenOffice.org, the you have to do the QA process and errata _every_
>  > single one of the i18n packages too, which is more administrative
>  > overhead. 
Just take a look at the update dates on the dictionnary download page.
They are *not* synched with oo.o releases.

In fact for some of them you could have an unchanged rpm for several FC
releases. That screams low maintenance packages to me.

And speaking as a lowly end-user, I'd rather search a bit for a spelling
package than learn yet another way to update my system (after
emacs/xemacs autoupdate, moz plugins, perl cpan, java maven, and so on).
Get real people ! Any single specialized update system will always be
simpler than a generic one like rpm. The problem with specialized
updaters is they pile up quicker than people can master them - even MS
realized lately this was no way to make system administration scale. Not
to mention they usually lack half the security/hardening features of
rpm.

I think the Gnome people have demonstrated pretty well people prefer
consistency to one-off displays of creativity.

Regards,

-- 
Nicolas Mailhot

Comments? (OpenOffice.org Dictionaries)

[Panu Matilainen]

On Mon, 12 Apr 2004, Nicolas Mailhot wrote:

>  > On Mon, Apr 12, 2004 at 01:08:14PM -0400, Dan Williams wrote:
>  > > An argument against individual i18n files is that if you have an errata
>  > > for OpenOffice.org, the you have to do the QA process and errata _every_
>  > > single one of the i18n packages too, which is more administrative
>  > > overhead.
>  
>  Just take a look at the update dates on the dictionnary download page.
>  They are *not* synched with oo.o releases.
>  
>  In fact for some of them you could have an unchanged rpm for several FC
>  releases. That screams low maintenance packages to me.
>  
>  And speaking as a lowly end-user, I'd rather search a bit for a spelling
>  package than learn yet another way to update my system (after
>  emacs/xemacs autoupdate, moz plugins, perl cpan, java maven, and so on).
>  Get real people ! Any single specialized update system will always be
>  simpler than a generic one like rpm. The problem with specialized
>  updaters is they pile up quicker than people can master them - even MS
>  realized lately this was no way to make system administration scale. Not
>  to mention they usually lack half the security/hardening features of
>  rpm. 
Seconded - each program having it's own auto-update/install mechanism is a 
hideous misfeature of Windows-world, lets not go there please. For example 
DicOOo doesn't seem to support proxies currently (and yes I've set up 
the proxies in OOo config) so it's unusable for me at work. Never mind 
that I seriously dislike random programs fetching stuff over the Internet 
to install something. I'd much rather see the language packs as gpg-signed 
rpm's.

	- Panu -

Comments? (OpenOffice.org Dictionaries)

[Michael A. Peters]

On Mon, 2004-04-12 at 22:26, Panu Matilainen wrote:

>  
>  Seconded - each program having it's own auto-update/install mechanism is a 
>  hideous misfeature of Windows-world, lets not go there please. 
Oh I agree - I like to be able to update without needing to launch the
app first to update it.

-- 
Cheap Linux CD's - http://mpeters.us/linux/

Comments? (OpenOffice.org Dictionaries)

[Colin Charles]

On Tue, 2004-04-13 at 13:26, Panu Matilainen wrote:

>  Seconded - each program having it's own auto-update/install
> mechanism is a 
>  hideous misfeature of Windows-world, lets not go there please. For example 
>  DicOOo doesn't seem to support proxies currently (and yes I've set up 
>  the proxies in OOo config) so it's unusable for me at work. Never mind 
>  that I seriously dislike random programs fetching stuff over the Internet 
>  to install something. I'd much rather see the language packs as gpg-signed 
>  rpm's. 
Shouldn't we stick to mainstream as much as possible?

We might as well get proxy support in DicOOo and that makes a whole lot
more sense - get it fixed upstream, and all is well for us
-- 
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/

Comments? (OpenOffice.org Dictionaries)

[Nicolas Mailhot]

Le mer, 14/04/2004 à 13:08 +0800, Colin Charles a écrit :

>  On Tue, 2004-04-13 at 13:26, Panu Matilainen wrote:
>  
>  > Seconded - each program having it's own auto-update/install mechanism is a 
>  > hideous misfeature of Windows-world, lets not go there please. For example 
>  > DicOOo doesn't seem to support proxies currently (and yes I've set up 
>  > the proxies in OOo config) so it's unusable for me at work. Never mind 
>  > that I seriously dislike random programs fetching stuff over the Internet 
>  > to install something. I'd much rather see the language packs as gpg-signed 
>  > rpm's.
>  
>  Shouldn't we stick to mainstream as much as possible? 
We do not stick to upstream when upstream habits are contrary to core
distribution processes.

The Fedora install/update system is rpm, and nothing else. I hear no one
clamoring for restauration of the other custom update processes Fedora
already ignores.

Cheers,

-- 
Nicolas Mailhot

Comments? (OpenOffice.org Dictionaries)

[Alan Cox]

On Mon, Apr 12, 2004 at 10:31:55AM -0400, Dan Williams wrote:
>  language in Anaconda.  However, what do you do after the fact?  How
>  would they be distributed?  How would you notify users of the additional
>  language packs' existence? 
yum, apt, up2date

just like kde and aspell

Comments? (OpenOffice.org Dictionaries)

[André Kelpe]

Am Mo, den 12.04.2004 schrieb Dan Williams um 16:31:
>  Hi, 
>  > Do you think I should use one big source RPM for all the
> languages?  The
>  > down side of this is that the dictionaries are updated in an ad-hoc
>  > manner, so you would have to rebuild the whole lot if you only wanted to
>  > update one language.
>  >  
Does anybody know how other distributions solve this problem. Maybe
someone else had an idea which is easy to adpot and no pain to maintain.

The current setup isn't IMHO very well because you can't tell people to
use a (in my case) German office with an English help-system.

André

Comments? (OpenOffice.org Dictionaries)

[Dan Williams]

Hi,

I'm not even sure that's possible...  You mean a German localized UI,
but with the English help system?  Unless you physically remove the
German help, I don't think you'll get the English help when set to a
German UI.  What's the motivation for doing this? Wouldn't you want a
German Help too?

Dan

On Tue, 2004-04-13 at 09:46 +0200, André Kelpe wrote:
>  Am Mo, den 12.04.2004 schrieb Dan Williams um 16:31:
>  > Hi,
>  
>  > > Do you think I should use one big source RPM for all the languages?  The
>  > > down side of this is that the dictionaries are updated in an ad-hoc
>  > > manner, so you would have to rebuild the whole lot if you only wanted to
>  > > update one language.
>  > > 
>  
>  Does anybody know how other distributions solve this problem. Maybe
>  someone else had an idea which is easy to adpot and no pain to maintain.
>  
>  The current setup isn't IMHO very well because you can't tell people to
>  use a (in my case) German office with an English help-system.
>  
>  André
>  
>  
>  -- 
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-devel-list

Comments? (OpenOffice.org Dictionaries)

[Alan Cox]

On Tue, Apr 13, 2004 at 10:06:57AM -0400, Dan Williams wrote:
>  I'm not even sure that's possible...  You mean a German
> localized UI,
>  but with the English help system?  Unless you physically remove the
>  German help, I don't think you'll get the English help when set to a
>  German UI.  What's the motivation for doing this? Wouldn't you want a
>  German Help too? 
Give you one example where I've been asked exactly this - people learning
a foreign language want to write in that language, spell check in it,
but would rather have help in their native language.

(For most apps LANG= ... seems to sort people out, and for gnome you
 tend not to get translated docs for most languages anyway 8( )

Comments? (OpenOffice.org Dictionaries)

[Dan Williams]

Hi,

Certainly, you are not precluded from writing in German and
spellchecking in German.  The difference is that I do _not_ believe
(correct me if I'm wrong) that you can have the Help and the UI in a
different language.  These are both tied into what your LANG currently
is AFAIK (though it would not be past OOo to be weird just for the fun
of it).

However, if you set the language on a string of text to be German for
example, and turn on German spellchecking, you can write in German while
having an English UI.  I just don't believe that you can separate the UI
and the Help languages (nor should you be able to, OOo has 2x enough
preferences/options as it is).

Dan

On Tue, 2004-04-13 at 10:12 -0400, Alan Cox wrote:
>  On Tue, Apr 13, 2004 at 10:06:57AM -0400, Dan Williams wrote:
>  > I'm not even sure that's possible...  You mean a German localized UI,
>  > but with the English help system?  Unless you physically remove the
>  > German help, I don't think you'll get the English help when set to a
>  > German UI.  What's the motivation for doing this? Wouldn't you want a
>  > German Help too?
>  
>  Give you one example where I've been asked exactly this - people learning
>  a foreign language want to write in that language, spell check in it,
>  but would rather have help in their native language.
>  
>  (For most apps LANG= ... seems to sort people out, and for gnome you
>   tend not to get translated docs for most languages anyway 8( )
>  
>  
>  -- 
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-devel-list

Comments? (OpenOffice.org Dictionaries)

[André Kelpe]

Am Di, den 13.04.2004 schrieb Dan Williams um 16:06:
>  Hi,
>  
>  I'm not even sure that's possible...  You mean a German localized UI,
>  but with the English help system?  Unless you physically remove the
>  German help, I don't think you'll get the English help when set to a
>  German UI.  What's the motivation for doing this? Wouldn't you want a
>  German Help too? 
No, the point is that my OOo-UI is in German and the Help-System is
always English. I can't find a way to get a German help. Having the
help-system in English has the effect that you always have to guess how
the described help would be translated especially the menu-entries,
which is sometimes not easy because of the chosen names of menu-entries
in the translation.

André

Comments? (OpenOffice.org Dictionaries)

[F. Kooman]

On Mon, 2004-04-12 at 16:31, Dan Williams wrote:
>  Looking forward as the Fedora Core / Red Hat maintainer of the OOo
>  packages, what do people think I should do? 
You could add DicOOo.sxw to the Office menu items just like the
OpenOffice.org printer setup / repair, that way users will be able to
install the dictionaries they need via a menu item.

François
-- 
Please avoid sending me Word or PowerPoint attachments. 
See http://www.fsf.org/philosophy/no-word-attachments.html