I can confirm this. The dictionaries I installed from File -> Wizards - Install 
new dictionaries ... are gone. And worse, when I spell check, no error message. 
It just says "spell check complete"

This is so unprofessional!! You release updates every 3-4 months, and the 
upgrading OOo destroys your settings behind your back. This is a high priority 
fix!

And WHY does OOo install the same dictionaries, again and again? I DO NOT need 
the german and swahili dictionaries! Installing dictionaries should be handled 
from the setup program, and every update should respect the settings ever after.

*** Issue 72559 has been confirmed by votes. ***

46 votes and plenty of frustrations. How about an update on this one; just had
my settings smashed again when upgrading to 2.2.1, forgot how I fixed this last
time... frustrated!!!!

Laurent, is there something we can do together?

Changing the content of "share/dict" outside of setup is broken by design as
this issue proofs. I know that there is no other way at the moment, so it seems
that the time has come to start the linguistic refactoring I mentioned a few
months ago. 

Unfortunately it's possible that we don't have a developer available that feels
responsible for the lingucomponent code in a way that he will take that task
over. So in the worst case Thomas Lange had to do it. I'm willing to support
that in case you can find some time to change DictOOo.

While we are at it, we can also think about using extensions (packages) for the
dictionaries but that's only an option.

@sajer: installing dictionaries in setup is not possible due to licence reasons.
We can only install those who have LGPL but they usually have GPL.

So we had to create a separate installer, the DictOOo that thankfully was
provided by Laurent. Unfortunately the lingucomponent misses means to access
common dictionaries from anywhere else than "share/dict". This is what we must
change. 

But it is not a fast change and unfortunately the lingucomponent code is
partially orphaned since Kevin Hendricks has left. This explains why nobody has
started working on this issue despite the fact that 46 votes is a lot for a defect.

I confirm it is an awful bug, and very curious because we are in 2007...
I will look for the next version (after 2.2.1) and perhaps I will change...

Then you have to find another programmer, and faster than ASAP. This bug is a
true show stopper, and I cannot see why other features like enhanced PDF export
etc should be more important than fixing this issue. EVERY time I upgrade OOo my
settings are destroyed. Okay, so I don't. I start missing MSO. Others might hear
about issues like this and ... run away.

You just cannot orphan any code in an office suite and a huge project like this.
Some bugs can wait but this one. If your prioritize not to fix this, then it is
a horrible example of running a project to its early grave.

Please let me try to de-emotionalize the discussion and get back to the facts.

If dictionaries are installed per user all files and the necessary information
about them are stored in the "user" layer of OOo. In this case an update of OOo
shouldn't delete any dictionaries or dictionary configurations. (In case I'm
wrong here please let me know.)

So the only way how OOo can destroy dictionaries or dictionary configurations is
when dictionaries have been put into the "share" layer. This will happen in two
cases: 

(1) Manual installation of dictionaries
(2) "Administrative setup" of DictOOo (the dictionary wizard of OOo)
(The "Current User Setup" of DictOOo is no problem as the dictionary and
dictionary configuration files are placed into the "user" layer and the
situation is as described above.)

I would be pleased to hear which scenario was used by the users who have been
hit by the problem or if other scenarios have been used that I'm not aware of.

While scenario (1) is unsupported and discouraged case (2) is the problem.
Whatever we do in the OOo source code to fix the problem it will fail as long as
the "Administrative setup" of DictOOo is carried out in the way it is
implemented now. We need a new implementation for this mode: administrative
installation of dictionaries must use dictionary extension packages and *never*
change any files in or add any new files to the "share" layer. To make it simple
dictionaries should be installed as extensions always, in both modes. 

Work has been done to prepare the OOo source code to deal with dictionaries
installed as extensions (see Child Workspace tl41 - I made this issue dependent
to the issues added to the CWS). We think that this code can be ready and tested
for OOo 2.4.

Now we need to create extensions from all existing dictionaries. We (the OOo
developers) can do this for all dictionaries that are hosted in our cvs but we
need to get in touch with all other contributors that currently host
dictionaries on their own websites. We will start a discussion about that on the
lingucomponent mailing list soon. 

Until then there is a simple though perhaps sometimes painful workaround: don't
use the "Administrative Setup" of DictOOo.

The target "2.x" should reflect that we still need the commitment of the
external contributors to fix the problem completely. We hope to deliver a fix
for the most common dictionaries (those we can manage ourselves) in 2.4.

I think, the descriptions are not precise enough. Here is, what I notice:
Using DictOOo with option "for all", selecting Spain dictionaries(wordbook,
hyphenation, thesaurus).

After Installation, User has not run OOo:
(1) Nothing is changed in the user-directory. (OK)
(2) The file dictionary.lst in share\dict\OOo has got the correct three Spain
lines. Nothing else is changed there. (OK)
(3) There is a new file "Linguistic.xcu" in \share\registry\data\org\openoffice.
That's the real problem! If you delete this file immediately, no problems occur.

After User has run OOo and set the document language:
(4) The User "linguistic.xcu"-file has been changed, but it seems to be wrong.
If I later on copy this file in the user directory, the new language Spain is
not detected. Directly, when starting first time, you cannot notice it, because
the ABC in front of the language is there.

After user started OOo second time:
(5) The User "linguistic.xcu"-file is replaced by another "linguistic.xcu" file.

Isn't it possible to prevent, that the "linguistic.xcu"-file in
\share\registry\data\org\openoffice is generated?

I've saved the files in between and can send them to you if they are useful for you.

Thank you, Regina, for the detailed description. We will investigate this and
come back soon.

Hi Regina, thank you for your comments let's go some more into details.
Since this issues is about a upgrade problem:
(1) what was the OOo version before the upgrade?
(2) To which version did you upgrade?
(3) how did you upgrade? By applying a patch (which one?) or by installing 
    a full version and importing the old settings?
(4) when did you download your dictionaries? Before or after the upgrade?
(5) I don't think it matters, but just in case: which dictionaries did you 
    download. And which options did you choose with DictOO?
(6) Also just in case: which OS do you use?
(7) Which specific problem did you encounter after the upgrade?  
    Did only a specific dictionary for spellchecker etc. not work?
    Or were it all of them or only several.

Also I like to have a look at a number of files after the upgrade please pack
them in a zip archive and attach them to this issue or send them to me directly.
The list of files is:
(a) Depending on your OS:
    Windows: the bootstrap.ini from the 'program' directory.
    Linux  : the bootstrap.rc  from the 'program' directory.
(b) the dictionary.lst from the 'user' layer along with a directory listing
    (should be in user/wordbook)
(c) the dictionary.lst from the 'share' layer along with a directory listing
(d) The Linguistic.xcs (should be found only in 
    share\registry\schema\org\openoffice\Office)
(e) the Linguistic.xcu from the 'user' layer and the path name of that file
    (usually found in user\registry\data\org\openoffice\Office)
(f) the Linguistic.xcu from the 'share' layer and the path name of that file
    (Actually there should *never* be a Linguistic.xcu in the 'share' layer. 
    This file should only exist in the 'user' layer)
    Maybe it was a Linguistic.xcs?

If you have any of the above files from before the upgrade those would be
welcome too, but probably it will not be necessary.

About the possibility of creating a Linguistic.xcu in the share layer:
It should not happen! The only way I see how that could happen is when the user
layer was configured to point to the share layer. Thus I asked for the
bootstrap.ini/rc

DicOOo creates an entry in linguistic.xcu as an attempt to activate newly
installed dictionaries

The isAdmin is true if share layer is writable so it may mead to true under
windows. Then the providerService points to nthe share layer and then trying to
access /org.openoffice.Office.Linguistic/ creates it ?

the problem is that the problem is not systematic, so i don not see this as a
flaw in the routine, but feel free to point me on any problem

here is the code

sub WriteLinguisticSettings(language, country, dictype)

' check for access level
if isAdmin then
	providerService = "com.sun.star.configuration.AdministrationProvider"
else
	providerService = "com.sun.star.configuration.ConfigurationProvider"
endif

'create registry configuration access service
Dim aSettings, aConfigProvider
Dim aParams2(0) As new com.sun.star.beans.PropertyValue
aConfigProvider = createUnoService(providerService)
aParams2(0).Name = "nodepath"
aParams2(0).Value = "/org.openoffice.Office.Linguistic/"
aSettings = aConfigProvider.createInstanceWithArguments(
"com.sun.star.configuration.ConfigurationUpdateAccess", aParams2() )

locale = language + "-" + country

select case dictype
   case "DICT"
   		settingObject = aSettings.servicemanager.spellcheckerlist
   		settingLastObject =  aSettings.servicemanager.LastFoundSpellCheckers
   		service = "org.openoffice.lingu.MySpellSpellChecker"	
   case "HYPH"
   		settingObject = aSettings.servicemanager.hyphenatorlist
   		settingLastObject =  aSettings.servicemanager.LastFoundHyphenators
   		service = "org.openoffice.lingu.LibHnjHyphenator"
   case "THES"
   		settingObject = aSettings.servicemanager.thesauruslist
   		settingLastObject =  aSettings.servicemanager.LastFoundThesauri
   		if OOoVersion < 190 then
   			service = "org.openoffice.lingu.basic.Thesaurus"
   		else
   	   		service = "org.openoffice.lingu.new.Thesaurus"	
   		endif  	
end select

if settingObject.hasByName(locale) then
	settingObject.replaceByName(locale, service)
else
	settingObject.insertByName(locale, service)
endif

aSettings.commitChanges()

if settingLastObject.hasByName(locale) then
	settingLastObject.replaceByName(locale, service)
else
	settingLastObject.insertByName(locale, service)
endif

' force to re-eveluate the whole linguistic.xcu file
aSettings.servicemanager.DataFilesChangedCheckValue = -1

aSettings.commitChanges()

end sub

tl->laurent: I'm not yet done with my investigation but I can confirm that just
by running you macro below with isAdmin set after the next Office start nothing
will work anymore. (I don't need to install dictionaries to have this effect). 
I'm a bit puzzled because adding sth to the share layer xcu should not have this
effect (unless the user layer xcu has still meaningful content).

This even happens even though the settings in Tools/Options/.../Writing Aids say
everything is fine and available!
But there is also an easy work-around for the problem.
On the "Writing Aids" page itself where the three check boxes for spell checker,
hyphenator and thesaurus are you just need to do the following:
- unceheck each of the 3 entries then check all of them again and leave the
dialog via the 'OK' button.

Right after this everything will be fine again.

->Laurent: Actually two problems met here in this issue:
a) as MBA described installing in the share layer is a problem in itself
   (at least for later add-ons that were not part of the original installation)
b) the change to the xcu in the share layer should not have had this effect

If I have to make a quick but maybe wrong guess about the problem with the
entries you make in the share layer xcu it will be this:
- In the user layer xcu all the Spellchecker, Hyphenator, LastSpellchecker, ....
list are using oor:type="oor:string-list"  for their entries. Which maches the
setup in the xcs file.
- the entries you make use oor:type="xs:string" which is a type mismatch and
will probably trigger an exceptin when the user xcu is read. Because of this we
will also likely have a Linguistic.xcu.bak in the user layer which usually
remains when an exception was encountered.


Also you need not all make entries in the linguistic xcu in order to have new
installed dictionaries functional. You leave everything to OOo.
The DataFilesChangedCheckValue was originally setup to check the pathes
share/dict and share/dict/ooo for any changes and activate new installed
dictionaries and everything was fine.
Then you and I had a communication failure: I was not aware that because of
another issue you need to install downloaded dictionary now to user/wordbook
(which was not included in the calculation for DataFilesChangedCheckValue). Thus
you needed a change in the user layer xcu to make those dictionaries work. If
you had told me about this new installation path I could have just extenden the
evaluation of DataFilesChangedCheckValue to that path as well. Actually sometime
after I found out that there is a new installation path (which was probably
already several month after it was used first) I extend the pathes to look in by
user/wordbook. That missed to tell you as well... -_-°
The bottom line is: since some time ago in current Office versions you need no
longer make changes to the xcu in order to have your downloadable dictionaries
functional by default. The 'auto-detect' feature will take care of it in
user/wordbook as well. Your task could be scaled down to just keep the
dictionary.lst in shape.

Finally just let me remind you again that the statement a) from MBA is still
valid! Thus the only good work around to prevent the problem for the time being
is to not use administrative installation!
And in the longer run we should go with extensions.

Please excuse me, that I don't notice the part "update" of this issue. What I
notice is not the situation when updating, but when using DictOOo. But I think
that it is the real problem.

To test it once more, I installed 2.1.0de on WinXp, kind: complete, for all;
install French with DictOOo1.6.2, kind: for all; manually setting # in dict.lst
for to prevent unwanted languages.

After that I installed OOo2.2.1de, kind: complete, for all. It makes a new
directory for the program-file, but no new directory for the user-files. I then
run the dictionary wizard again with French, kind: for all.

I collect all the file you ask for. I add _user and _share to the filenames to
distinguish them.

In my first tests I use a "setup.exe -a" installion with change
UserInstallation=$ORIGIN/../..
in the bootstrap.ini. Now I didn't change the bootstrap.ini, but I got again a
linguistic.xcu in the share folder when running DictOOo.

The problem with this file is not about the setting in part "linguistic", but
about the setting for the default document language.

Created attachment 47529 [details]
Collection of files made on different points of installation process

@regina: is your winXP OOo share directory writable by the user installing ?
@tl: i'll have a detailled look at your response

@laurentgodard: Yes, that is usual setting for a WinXP Home.

TL->Regina, Laurent: Thank you for you files. They were useful.

What I can conduct from further analysis and experimenting is the following:
- not always will running DicOOo result in _immediate_ problems, not even if 
  it is run in administrative mode. The problem here is somewhat more 
  complicated and also depends on what dictionaries are already installed and
  who made the entries for that languages in the xcu's.
- despite previously having said that always using "current user" installation
  only will avoid the problems, I now sadly have to confirm that even a 
  "current user" installation _can_ result in at least a _partial_ _loss_ of 
  linguistic functionality!!
  (only the share layer dictionaries will still work)
  There is a rather specific setup to get this kind of problem...
- also you always loosing the setting with the default language has to do with
  mismatching entries in the xcu's. If there is a mismatch/error in a 
  configuration that whole file will be considered as being corrupted and all
  it's entries get discarded. If the error was in the user layer xcu and the 
  share layer configuration entries are all still fine the share layer 
  configuration will be used. (Please note that the share layer configuration 
  is actually multi-layered and there may be more than one file that modifies 
  entries belonging to the Linguistic.xcu)
  If the share layer xcu is corrupted the user layer won't be read at all and
  the result is implementation depending.
- For the very same reasons described above (mismatch/errors in the xcu files)
  my previously posted work-around will only do for the current session the 
  OOo is running. After the next start it will all be the same and you one 
  needs to apply that work-around as well.
- The only 'permanent' work-around (at least until DicOOo is used again or 
  OOo is actually upgraded!) is to shut down OOo and manually remove the
  linguistic.xcu's in the share layer and the user layer.
  Upon the next start the 'auto-detect' feature should enable all available
  dictionaries by deflaut. 
  Of course changes you made manually before e.g. to the default document
  language need to be done again. After that the user should be fine.

I will talk about the detailed problems with Linguistic.xcu, DicOO and the
upgrade process with Laurent in private mails now, since I think it may start a
longer thread and that need not be part of this issue.

->Regina: It would just be great if you could confirm that deleting both
Linguistic.xcu's will fix your problem for the time being. So other users with
the same problem can do similar.

Note: Just for the books I experimented with OOo-m217 andf OOo-m225 and used
DicOOo 1.7 for both.

Don't hesitate to ask questions at www.oooforum.org where numerous questions
were asked about this.

And see threads like this one: http://www.oooforum.org/forum/viewtopic.phtml?t=50862

Search for linguistic.xcu

it is the perfect place to ask. Mailing lists and this complicated Linix-like
issue handling system does not attract as many casual users as the forum.

Deleting the linguistic.xcu from the share folder solves the problem for me. All
settings are persistent then. If your spellcheck doesn't work, it is enough to
control the settings in writing aids > Edit moles once. I need not to delete the
linguistic.xcu in the user folder, but of cause I don't know others situation.

Advice till fix is available would be: After installing a language with DictOOo,
immediately delete the linguistic.xcu in the share folder, _before_ starting OOo
again.

Deleting (or renaming) Linguistic.xcu in 'share' was solving the linguistic
problems after using DicOOo for me (and others on English and German language
users mailing lists) several times.

See also issue # 72957 ...

Please pay attention.
The described problem from hagar_de_lest concerns the installation of a new OOo
version (update) not using 'DicOOo'. The main problem here is that the default
files in share/dict/ooo will be replaced during the update, especially the file
'dictionary.lst'. 
If you have changed the dictionary configuration, it will be lost after the update. 

For example the content of my share/dict/ooo folder:
de_frami_neu.aff
de_frami_neu.dic
DicOOo.sxw
dictionary.lst
en_GB.aff
en_GB.dic
en_US.aff
en_US.dic
FontOOo.sxw
hyph_de_DE.dic
hyph_en_GB.dic
hyph_en_US.dic
th_de_DE_v2.dat
th_de_DE_v2.idx
th_en_US_v2.dat
th_en_US_v2.idx

During the update all files, excepting 'de_frami_neu.*' will be deleted and
replaced by those of the install package. 
Concerning the dictionaries normally no problem, but the 'dictionary.lst' whose
content is different from the older one.

Workaround: Replace the new Dict/OOo folder with the saved old one.

jollat is completely right. The long and interesting discussion above should
have taken place in issue 72957 (which deals with this very linguistic.xcu
file), not here.

I confirm that deleting the linguistic.xcu in the share folder IS the
workaround. I've advised this from the beginning and it has always been fine
afterwards.

The issue I reported here deals with the dics FOLDER which is REPLACED at
installation or upgrade of a new OOo version (no dictionary installation).

Thanks.

The problem on update will be solved with the comming installation of
dictionaries as extensions

For the linguistic.xcu problem, please find an attempt of workaround on the
attached file, it is a preview of a coming 1.8 DicOOo version

Please do as quick as possible for reviewing/testing and give feed back so that
we may insert it in the coming 2.3 version if possible

Created attachment 47576 [details]
DicOOo 1.8 prototype

target 3.0 (as this needs changes in the configuration that should be done in a
major release only)

*** Issue 83797 has been marked as a duplicate of this issue. ***

With CWS tl41 the infrastructure to solve this problem will be given.
The actual fix however does require not to use the dictionary.lst anymore.

When CWS tl41 is integrated I will assign this task to whoever will take care of
providing dictionaries as extensions and/or making proper configuration entries
for the pre-installed dictionaries. When all the pre-installed and the down
loadable dictionaries are used that way then this issues will be fixed.

In the mean time I will temporarily take ownership of this issue in order to not
miss it.

.

*** Issue 89211 has been marked as a duplicate of this issue. ***

mba wrote:

"target 3.0 (as this needs changes in the configuration that should be done in a
major release only)"

Has this issue been resolved in the current OpenOffice.org 3.0 Beta? If so, will
I need to copy in my 2.3.1 [linguistics.xcu] file and [dictionary.lst] file from
the /share/dict/ooo folder, or has that structure been changed with 3.0? I'm
assuming it has not been fixed in release 2.4.0, based on mba's comment.

Yes, starting with OOo3.0 (Beta) we provide a new dictionary configuration that
won't overwrite user specific settings when the version is updated.

To make the transition easier for the beta users we still support the old
mechanism in the beta. This will be changed when 3.0 comes out.

Thanks for your reply mba:

"To make the transition easier for the beta users we still support the old
mechanism in the beta."

I installed the latest OOo 3.0 beta into a Windows XP system and setup the
Options as they were in a version of OOo 2.3 on the same system, except for the
new options, of course. That was the easy part. OOo 3 works great, and all of
the custom templates load without a problem. Trying to setup the dictionaries
has proved less simple. I'm probably overlooking a simple step, but I can't
figure it out.

I used the "install new dictionaries" wizard in Beta 3 to download and install
the dictionaries I want. It properly downloaded the Zip files to the
\OpenOffice.org\Basis 3.0\share\dict\ooo folder and automatically unzipped them
into that folder, informing me that the dictionaries had been installed.
However, on restarting OOo 3 they were not available in the Options—>Language
Settings—>Writing Aids—>Available language modules list. Only the default
installed languages were. I decided to try the old method and replaced
OpenOffice.org\Basis 3.0\share\dict\ooo\dictionary.lst.1st, OpenOffice.org\Basis
3.0\share\dict\ooo\dictionary.lst, and
OpenOffice.org3\user\registry\data\org\openoffice\Office\Linguistic.xcu with the
files from the OOo 2.3 installation that had only the dictionaries and all that
I wanted listed in them and none of the Swahili, Zulu, or other languages that I
did not want . In OOo 2.x this method was all that was needed to have the
languages I wanted listed in the [Available languages modules]. However,
changing those files in OOo 3 does not seem to make any impression on it.

Using the "install new dictionaries" wizard [DicOOo.sxw] does not add
dictionaries it installs into the dictionaries available list. Is this the way
it is supposed to work? How do I make OOo 3 see new dictionaries that are
installed into the \OpenOffice.org\Basis 3.0\share\dict\ooo folder? How do I
tell it which ones I want to be listed as available modules?

Thanks for your help. I apologize if I am missing something really simple.

mba — I got the dictionaries working. I have not rebooted the system at all
since my above post, so that is not a reason for the change. I have opened and
reopened OOo 3 beta many times since my last post, never finding the
dictionaries I installed being listed as available. However, OOo 3 beta is now
reading the language files noted in my last post and listing the dictionaries I
want as avaiable. The only thing that I have changed since that post is
reassigning the extensions in Windows XP.

Although I had selected to have OOo 3 beta be my default program to open MS
Office documents during installation, there were no changes made to the
extension associations. That is, all OOo extensions and MS Office extensions
were still assigned to open with OOo 2.3.1, including all OOo configuration file
extensions. I don't know if the associations were left unchanged by design
because OOo 3 is a beta or if this is a bug in OOo 3. Moreover, all of the OOo
configuration file associations still had "OpenOffice.org 1.1 configuration
file" as their description, although all linked to OOo 2.3.1. This seemed an
overdue correction.

After reassociating all OOo file extensions in Windows XP, I then tried opening
several .doc, .ods, and other OOo associated files to make sure that they now
opened in OOo 3 beta rather than OOo 2.3.1. They did. I also typed several
Spanish and several English words into a new document and once again tried the
SpellChecker. This time, the dictionaries I wanted were the only ones available.
I was very happy.

@spurred_on :

Did you also shut down the OOo quick start in the systray before attempting to
access your new dictionnaries ?

Howdy sle1306

"Did you also shut down the OOo quick start in the systray before attempting to
access your new dictionaries ?"

Yes!  I'd forgotten about that, but I did that just after reassociating the
extensions. I had checked not to have it load with Windows, but had not closed
it from the tray after installation. So that's what made OOo 3 see the
dictionaries. Interesting.

Thanks for solving the mystery.

Currently (in Beta) our dictionary extensions don't have "live deployment" and
you need a complete restart (incl. Quickstarter) to make them active. This
should not be necessary in the 3.0 final version.

Thanks for helping us with testing.
Is there anything else that is unclear?

Please understand that we won't fix any problems of the Dictionary Wizard in the
Beta as it will be removed in 3.0. 

.

Because of the other changes in this CWS and further changes from other already
integrated CWSs (namely removal of dictionary.lst and introduction of dictionary
extensions) this issue is obsolete now.

SBA: Verified in CWS native156. 

But in terms of "one dictionary works for different language locales (i.e. en_UK
spellcheck for en_ZA). this was a problem with the Englisch Dict Extension that
brings en_US, en_UK and en_ZA that must work based on the same dicts inside).

*** Issue 55920 has been marked as a duplicate of this issue. ***

TL->SBA: Since this one is already fixed and verified I think you should be the
owner and close this issue once the fix arrives in the master.

ok in m28 - dictionaries installed as extensions are available without restart,
no dictionary.lst anymore.. → closing.

Could someone answer the question raised when I filed this report:
When upgrading, will the dictionaries installed for all users (i.e. as an
extension in installation folder instead of the user profile) be deleted or not?

Sorry if this is a basic question but I'm still struggling with the new
dictionaries management, trying to track down all the configuration files
impacted. And I don't see any evidence that the extension in the installation
folder are kept.

If yes, then, fine, the issue is indeed fixed.
If no, then, I think this issue has to be re-opened.

I'm so lost that I mixed the proposals in previous comment:
If the extension in installation folder is NOT deleted, then it's fine.
If the extension is deleted, then the issue is not fixed.

There are two kinds of dictionaries installed for all users: those that are
bundled with OOo and those that are installed later. The first should be removed
when OOo is deinstalled, the second shouldn't.

What do you mean?
Aren't the dics for all users installed in the installation folder (vs. user
profile)? If so, can OOo make the difference at uninstall???

If the bundled dics are removed, are they reinstalled at next upgrade?

I mean that OOo should only deinstall files that is has installed and in case
any files are left in a folder the folder should be left also. This is the only
way how dictionaries could "survive" an update. IIRC this was true in older
versions also, but in these older versions OOo additionally overwrote the
dictionaries.lst file. Now bundled extensions in newer versions should become
installed next to the old ones (or in case they are installed already may be
update them).

So it means that if a dictionary (for 'All users') is removed by admin (because
no need of that language and to clear the tickmarks in the languages list), it
may be reinstalled at upgrade.

Yes; I don't know any way how global configurations could survive a complete
reinstallation.

My understanding was that the main reason why this issue is so popular was that
we deleted all additional dictionaries. Reinstalling some removed ones isn't
such a big issue IMHO because we have 2-4 of them only per installation set.

If you still think that this is worth a fix we should put this into another
issue to avoid confusing things. IMHO this also would go beyond dictionaries,
one might consider other configuration settings also.

I would reopen this issue here only if dictionary extensions installed after the
OOo installation would be removed on reinstallation.

Agreed. That sounds logical.

Will see if that removed dictionaries situation comes often in forum.

Thanks for the explanations!

mba said, 

"IMHO this also would go beyond dictionaries,
one might consider other configuration settings also." 

Extensions should be treated this way. In RC1 I have installed various
extensions. Some I installed as available for all users; some I was unable to
install for all users because they required each user to agree to a license.
Those extensions that are placed in an individual user's profile should not be
deleted or overwritten in an update. What happens to extensions that are
installed globally when OOo is updated? Are they deleted or overwritten, or do
they survive an update?

Treatment of extensions may seem like a separate issue from treatment of
dictionaries, but with OOo 3 dictionaries are extensions. Installing an update
of OOo should treat user installed extensions and dictionaries in the same
manner and should leave both survivable in an update, whether they be globally
or locally installed.

Tony

In general I agree to this, but with the exception of pre-bundled extensions.
They should be seen as part of the installation (it's an implementation detail
that they are extensions and not single files somewhere in "share") and so it's
only natural that they are removed when the application is deinstalled.

OTOH if a user explicitly installs a dictionary it should not be deinstalled
automatically when OOo is deinstalled (e.g. in an update procedure). This is
definitely true for dictionaries and all other extensions that are installed for
a single user. I think the same is true for dictionaries and other extensions
installed for all users, but I haven't tested that, I assume that the QA has
checked that before this issue was closed.

For information, installing a dictionary the old way in OOo 3 still works fine
(even with the wizard DicOOo)!!!
I just tried on W2k with OOo 3 putting the old files (from the 2.4.1 profile) in
my user profile .../wordbook folder (including the dictionary.lst).

tl-> hagar_de_lest:Well, thank you for reminding me about that. I'll look up
into it tomorrow and going to remove that code part...

I am not smart rnough to undestand all this. I need a spell checker and have
tried every thing to get it back. Please in plain alnguage tell me how.
  
Bud

kc7hxy1@aol.com

Thank you for your help

[ pointed Bud via mail to the community help resources ]