Issue 45725 - check if dictionary.lst entries exist at load time
Summary: check if dictionary.lst entries exist at load time
Status: CLOSED FIXED
Alias: None
Product: Infrastructure
Classification: Infrastructure
Component: Website general issues (show other issues)
Version: current
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: hjs
QA Contact: issues@lingucomponent
URL:
Keywords:
: 46413 (view as issue list)
Depends on:
Blocks:
 
Reported: 2005-03-22 08:54 UTC by caolanm
Modified: 2013-02-24 20:34 UTC (History)
7 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
patch to implement (11.61 KB, patch)
2005-03-22 08:55 UTC, caolanm
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description caolanm 2005-03-22 08:54:34 UTC
The following patch checks to see if the dictionary.lst entries actually exist
on disk. This allows invalid missing entries to be filtered out. 

The advantage of this is that is it allows the dictionaries to be listed in
dictionary.lst as a list of possibly installed dictionaries, and the actual
dictionaries to be split up amoung the language packs by distributers of OOo
Comment 1 caolanm 2005-03-22 08:55:01 UTC
Created attachment 24136 [details]
patch to implement
Comment 2 pavel 2005-03-22 18:14:11 UTC
caolan: I thought about similar approach: make the code parse all *.lst files in
the directory. Thus language pack can deliver its own dictionary_ISO_code.lst
file (e.g.).

What do you think? What about combining both approaches?
Comment 3 caolanm 2005-03-22 18:45:29 UTC
Sure, that would suit me as well. The goal simply being to be able to seperate
the dictionaries from eachother. Though there are various macros in existance
around the existing dictionary.lst which would be a pain to have to rework in a
split dictionary.lst model.
Comment 4 stx123 2006-02-16 23:35:07 UTC
Hm, so what does this mean for the patch?
Is somebody going to integrate it as is or would you like to work on the
proposed combined approach?
Comment 5 pavel 2006-02-17 07:39:14 UTC
Caolan: Kevin is no longer active. Do you still use this patch?
Comment 6 maison.godard 2006-02-17 07:55:13 UTC
let me know the choice you made about .lst as DicOOo is concerned
structurally there should be no problem (moving .lst parsing in a loop)
simply more work ... and have to handle backward compatibility though

Laurent
Comment 7 caolanm 2006-02-17 10:26:12 UTC
I still use this patch, Is there no active maintainer for this code anymore ? I
can take care of applying the simple approach patch if there's no maintainer.
Comment 8 fabbio 2006-02-23 13:52:30 UTC
I propose to create a different dictionary.lst for different localized build. 
Example for Italian build, the dictionary.lst have to contain only the IT rows,
but now includes a lot of rows so OOo is too slow when loading. 

Is possible to include a question in OOo's first run dialog, (when asking user's
data, and registration....) where the user can select the dictionary to include
in dictionary.lst improving OOo start-up.

Users can always add new dictionary later using DictOOo or editing
dictionary.lst like info reported in dictionary's readme file.

At the moment I have to delete the row of other language in dictionary.lst every
time I install a new OOo version.

FaBBio
Comment 9 caolanm 2006-02-23 14:03:51 UTC
that isn't what this relatively simple patch/task is about.
Comment 10 caolanm 2006-03-10 10:31:17 UTC
fixed in cmcfixes24, the basic path to sanity test that dictionaries in the list
actually exist.
Comment 11 caolanm 2006-03-27 10:15:13 UTC
reopen for qa
Comment 12 caolanm 2006-03-27 10:16:10 UTC
reassign for qa
Comment 13 caolanm 2006-03-27 10:17:51 UTC
back to fixed. Strangely can't seem to set a 2.0.3 target for this bug
Comment 14 hjs 2006-03-31 09:47:44 UTC
looked at by some friendly developer :)
Comment 15 lsuarezpotts 2006-04-06 14:56:39 UTC
btw, "whiteboard" is not really a used component any longer; the project was mothballed. Lingucomponent 
is the proper component for this
Comment 16 hjs 2006-04-20 12:19:45 UTC
.
Comment 17 nemeth.lacko 2006-08-08 22:58:39 UTC
*** Issue 46413 has been marked as a duplicate of this issue. ***