[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries



On Friday, October 14, 2022 3:54:53 AM MST Roland Rosenfeld wrote:
> - Where should the bdic files be placed?
>   1) /usr/share/hunspell-bdic

I like this option because it would eliminate the need to wait to find out if 
Chromium can use the files before deciding where to put them.

On a separate note, I am in the process of filing upstream bug reports with 
Google as recommended by Qt.  Once I get those filed I will place links to them 
in the Qt bug reports.  I don’t think we need to wait for these bugs to be 
fixed before adding packages to Debian as they only affect three languages, but 
if the .bdic files are going to be generated automatically we need some 
mechanism to specify that they shouldn’t attempt to be generated for these 
three languages until the bugs are fixed.

Alternatively, we could patch the files so that the errors are avoided.  In the 
case Aragonese with tabs in the .aff, we could change them all to be spaces.  I 
can find no Hunspell file spec that says either tabs or spaces are required, and 
I am assuming that Hunspell itself doesn’t have problems with tabs because 
there are no nasty bugs filed against the current Aragonese Debian package, but 
it should also work fine with spaces as that is what all the other Hunspell 
packages appear to use.

The errors in the other two files could be fixed by removing one line from ar.aff 
and 31 lines from gl_ES.dic.  That makes them slightly less correct, but most 
people using the .bidc would probably not notice.  If we go this route we need 
to make sure we are only editing temporary files used to generate the .bdic as 
those using the standard Hunspell system should not end up with an inferior 
experience just to accommodate a custom binary format.

-- 
Soren Stoutner
soren@stoutner.com

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: