+++ This bug was initially created as a clone of Bug #64382 +++ An updated Lithuanian spell checker dictionary did not work in a new LibreOffice installation, and the cause was determined to be a change introduced by upstream (ispell-lt): Property "Locales" was changed from lt-Lt to lt in dictionaries.xcu The dictionary was updated with this commit: https://gerrit.libreoffice.org/gitweb?p=dictionaries.git;a=commitdiff;h=143afd75257fd4c4b44f09ee402ec8caa09011ba#patch7 Changing --- <prop oor:name="Locales" oor:type="oor:string-list"> <value>lt</value> </prop> --- back to --- <prop oor:name="Locales" oor:type="oor:string-list"> <value>lt-LT</value> </prop> --- in the installed share\extensions\dict-lt\dictionaries.xcu for new users fixed the problem. I believe that it a bug in LibreOffice spell checker which should work with Locales=lt just as well as with Locales=lt-LT?
Andras: I was comparing with other dictionaries, eg http://opengrok.libreoffice.org/xref/dictionaries/an_ES/dictionaries.xcu and saw that it's possible to put several values. So, could we change: <value>lt-LT</value> to <value>lt lt-LT</value> ? Or is it less "naive" than this?
In (In reply to comment #1) > Andras: I was comparing with other dictionaries, eg > http://opengrok.libreoffice.org/xref/dictionaries/an_ES/dictionaries.xcu > and saw that it's possible to put several values. > So, could we change: > <value>lt-LT</value> > to > <value>lt lt-LT</value> > ? Or is it less "naive" than this? In fact, that's what I did upstream for now. But I haven't got feedback yet about whether it works or not... In any case, that would be a temporary workaround for bug #64382, not a bugfix, and certainly, not a bugfix for this bug.
just for my information, why is it just a workaround and not a bugfix?
(In reply to comment #3) > just for my information, why is it just a workaround and not a bugfix? Because maybe you can write <value>foo bar baz lt lt-LT</value> there, and all but lt-LT will be just ignored.
(In reply to comment #3) > just for my information, why is it just a workaround and not a bugfix? Because the problem is that valid two-letter codes do not work in LibO, and I believe that they should. I explicitly mentioned that it the last sentence of the initial comment by the way. :)
If you're right and if I understand well, it means http://opengrok.libreoffice.org/xref/dictionaries/an_ES/dictionaries.xcu is wrong too, since we can see: 6 <prop oor:name="Locations" oor:type="oor:string-list"> 7 <value>%origin%/an_ES.aff %origin%/an_ES.dic</value> and in this case, what's the meaning of "string-list" here?
Sorry Julien, but I don't understand your question.
Rimas, the question was more for Andras but I meant : the xml file defines this field as "string-list", so we may expect being able to put several values like in http://opengrok.libreoffice.org/xref/dictionaries/an_ES/dictionaries.xcu So if it doesn't work, how does "string-list" work? Should it be: <prop oor:name="Locations" oor:type="oor:string-list"> <value>%origin%/an_ES.aff</value> <value>%origin%/an_ES.dic</value>
(In reply to comment #8) > Rimas, the question was more for Andras but I meant : > the xml file defines this field as "string-list", so we may expect being > able to put several values like in > http://opengrok.libreoffice.org/xref/dictionaries/an_ES/dictionaries.xcu > So if it doesn't work, how does "string-list" work? > Should it be: > <prop oor:name="Locations" oor:type="oor:string-list"> > <value>%origin%/an_ES.aff</value> > <value>%origin%/an_ES.dic</value> Oh, I think you misunderstood Andras' comment. I think his point was that from <value>foo bar baz lt lt-LT</value>, 'lt-LT' will be the only value treated as valid, because it conforms ll-CC form.
Any updates here?
Sophie I thought you might have an opinion on this one.
Set to New because both Rimas and Andras know better than any one what they are talking about :)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.