Issue 72559

Summary: Dictionary configuration deleted at upgrade
Product: lingucomponent Reporter: hagar_de_lest <hagar_de_lest>
Component: otherAssignee: stefan.baltzer
Status: CLOSED FIXED QA Contact: issues@lingucomponent <issues>
Severity: Trivial    
Priority: P3 CC: cno, issues, josef.latt, lohmaier, maison.godard, Mathias_Bauer, rb.henschel, stp, thomas.lange
Version: OOo 2.1Keywords: oooqa
Target Milestone: OOo 3.0   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on: 80286, 80287    
Issue Blocks:    
Description Flags
Collection of files made on different points of installation process
DicOOo 1.8 prototype none

Description hagar_de_lest 2006-12-14 09:12:05 UTC
When OOo is upgraded, the dictionary configuration (<OOo main
program>/share/dict/ooo folder) is overwritten by the new files. Therefore, all
the modifications (dics removed & added) are lost. Moreover, we get again all
the unwanted dics delivered by default with OOo.

The only way to avoid this is to put the folder content in the user profile
folder but it's not very smart and we keep receiving the whole bunch of dics by

This is not an enhancement but a defect because it has a serious impact on the
usability. Users have to download again some dics. See this thread :

The dictionary management must be changed to avoid this. At least files should
be added when non existent but NOT overwritten. And the dictionary.lst file
modified and never replaced.
Comment 1 sajer 2006-12-14 17:10:41 UTC
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 

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.
Comment 2 terrynorth 2006-12-23 01:52:22 UTC
*** Issue 72559 has been confirmed by votes. ***
Comment 3 sajer 2007-06-13 02:35:13 UTC
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!!!!
Comment 4 Mathias_Bauer 2007-06-13 07:14:06 UTC
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.
Comment 5 Mathias_Bauer 2007-06-13 07:20:15 UTC
@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

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.

Comment 6 brulain 2007-06-20 16:44:04 UTC
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...
Comment 7 skodaoffice 2007-08-06 21:35:42 UTC
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.
Comment 8 Mathias_Bauer 2007-08-13 15:18:03 UTC
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

(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.
Comment 9 Regina Henschel 2007-08-13 17:09:20 UTC
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.
Comment 10 Mathias_Bauer 2007-08-14 10:39:30 UTC
Thank you, Regina, for the detailed description. We will investigate this and
come back soon.
Comment 11 thomas.lange 2007-08-14 11:41:09 UTC
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 
(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
Comment 12 maison.godard 2007-08-14 11:59:12 UTC
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 = ""
	providerService = ""

'create registry configuration access service
Dim aSettings, aConfigProvider
Dim aParams2(0) As new
aConfigProvider = createUnoService(providerService)
aParams2(0).Name = "nodepath"
aParams2(0).Value = "/org.openoffice.Office.Linguistic/"
aSettings = aConfigProvider.createInstanceWithArguments(
"", 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"
   	   		service = ""	
end select

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


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

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


end sub
Comment 13 thomas.lange 2007-08-14 14:19:03 UTC
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.
Comment 14 Regina Henschel 2007-08-14 17:33:33 UTC
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
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.
Comment 15 Regina Henschel 2007-08-14 17:35:10 UTC
Created attachment 47529 [details]
Collection of files made on different points of installation process
Comment 16 maison.godard 2007-08-14 17:59:06 UTC
@regina: is your winXP OOo share directory writable by the user installing ?
@tl: i'll have a detailled look at your response
Comment 17 Regina Henschel 2007-08-14 18:47:56 UTC
@laurentgodard: Yes, that is usual setting for a WinXP Home.
Comment 18 thomas.lange 2007-08-15 14:13:43 UTC
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.
Comment 19 skodaoffice 2007-08-15 14:51:26 UTC
Don't hesitate to ask questions at where numerous questions
were asked about this.

And see threads like this one:

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.
Comment 20 Regina Henschel 2007-08-15 15:17:09 UTC
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
Comment 21 majukr05 2007-08-15 19:45:31 UTC
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 ...

Comment 22 jolatt 2007-08-15 21:05:31 UTC
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
If you have changed the dictionary configuration, it will be lost after the update. 

For example the content of my share/dict/ooo folder:

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.

Comment 23 hagar_de_lest 2007-08-16 08:24:54 UTC
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

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).

Comment 24 maison.godard 2007-08-16 21:18:31 UTC
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
Comment 25 maison.godard 2007-08-16 21:20:00 UTC
Created attachment 47576 [details]
DicOOo 1.8 prototype
Comment 26 Mathias_Bauer 2007-11-23 21:06:55 UTC
target 3.0 (as this needs changes in the configuration that should be done in a
major release only)
Comment 27 Mathias_Bauer 2007-11-27 21:11:12 UTC
*** Issue 83797 has been marked as a duplicate of this issue. ***
Comment 28 thomas.lange 2008-02-21 11:10:00 UTC
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.
Comment 29 thomas.lange 2008-02-25 13:03:17 UTC
In the mean time I will temporarily take ownership of this issue in order to not
miss it.
Comment 30 thomas.lange 2008-02-25 13:04:27 UTC
Comment 31 thomas.lange 2008-05-09 11:36:17 UTC
*** Issue 89211 has been marked as a duplicate of this issue. ***
Comment 32 spurred_on 2008-05-11 15:35:47 UTC
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 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.
Comment 33 Mathias_Bauer 2008-05-11 23:27:40 UTC
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.
Comment 34 spurred_on 2008-05-13 17:28:02 UTC
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
\\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\Basis 3.0\share\dict\ooo\dictionary.lst.1st,\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 \\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.
Comment 35 spurred_on 2008-05-14 01:31:01 UTC
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 " 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.
Comment 36 sle1306 2008-05-14 07:43:12 UTC
@spurred_on :

Did you also shut down the OOo quick start in the systray before attempting to
access your new dictionnaries ?
Comment 37 spurred_on 2008-05-14 14:03:36 UTC
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.
Comment 38 Mathias_Bauer 2008-05-16 16:28:42 UTC
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.
Comment 39 Mathias_Bauer 2008-05-16 16:30:26 UTC
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. 
Comment 40 thomas.lange 2008-06-25 16:18:48 UTC
Comment 41 thomas.lange 2008-06-25 16:22:06 UTC
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.

Comment 42 stefan.baltzer 2008-06-26 17:36:34 UTC
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).
Comment 43 cno 2008-07-01 23:29:50 UTC
*** Issue 55920 has been marked as a duplicate of this issue. ***
Comment 44 thomas.lange 2008-07-09 09:34:12 UTC
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.
Comment 45 lohmaier 2008-08-05 23:44:14 UTC
ok in m28 - dictionaries installed as extensions are available without restart,
no dictionary.lst anymore.. → closing.
Comment 46 hagar_de_lest 2008-09-15 21:52:27 UTC
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.
Comment 47 hagar_de_lest 2008-09-15 22:21:47 UTC
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.
Comment 48 Mathias_Bauer 2008-09-16 07:03:28 UTC
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.
Comment 49 hagar_de_lest 2008-09-16 20:45:41 UTC
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?
Comment 50 Mathias_Bauer 2008-09-16 23:09:05 UTC
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).
Comment 51 hagar_de_lest 2008-09-17 11:18:47 UTC
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.
Comment 52 Mathias_Bauer 2008-09-17 12:47:57 UTC
Yes; I don't know any way how global configurations could survive a complete

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.
Comment 53 hagar_de_lest 2008-09-17 19:53:49 UTC
Agreed. That sounds logical.

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

Thanks for the explanations!
Comment 54 spurred_on 2008-09-21 14:52:45 UTC
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.

Comment 55 Mathias_Bauer 2008-09-21 20:47:46 UTC
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.
Comment 56 hagar_de_lest 2008-10-28 16:46:39 UTC
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).
Comment 57 thomas.lange 2008-10-28 16:57:35 UTC
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...
Comment 58 plainbud 2009-09-15 02:00:47 UTC
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.

Thank you for your help
Comment 59 cno 2009-09-15 07:26:18 UTC
[ pointed Bud via mail to the community help resources ]