Hi Thomas, Just a note to keep you up to date.
The work we did with indexing multiple alternative 00-database-short entries is good, and something like it should be included in the revo package, but the problem definitely lies elsewhere. I finally downloaded your stuff, and even the database in your dict-revo_20050407.orig.tar.gz can't access its own 00-database-short entry, either when initializing or when looking up a definition. The index values provided are correct, but there are two other problems. First, the index is not sorted correctly: revo.cs.inx: 00-database-utf8 A T 00-database-url T w 00-database-short BD g 00-database-info Bj Bp a YZr Lu The only reason that dictd needs to know locale info, is for sort order. It looks as if the rest of the index is sorted correctly, but the 00-* headers are jumbled (reversed, actually, but this is probably just a coincidence). Second, dictd itself does seem to have a bug, and isn't getting at these entries (even when sorted) as long as there is a 00-database-utf8 header. I am trying to figure that out now. Earlier, you said: > By the way, the ReVo dictionary is encoded in UTF-8, so we faced the > well-known (#232227, #314325, etc.) dictd-locale-problem: if > /etc/default/dictd isn't modified by the user to add a > "--locale=foo_BAR.UTF-8", then dictd won't start anymore. This > problem is quite annoying since it won't allow dict-revo to work > out-of-the-box, as it doesn't currently allow dict-de-en to work > out-of-the-box. Any idea to fix this problem ? The problem is that, given the way that the locales package works (with locales built by locale-gen), there is no means that I know of to create a dependency on there being a UTF-8 locale built. Perhaps I need to make a dictd-utf8 package that utf8 dictionaries depend or possibly predepend upon. This package would require a "* UTF-8" entry in /etc/locale.gen or would prompt a user for one, or even add a default one, possibly en_US. (Is there one more generic?) It would then run locale-gen and ensure that a UFT8 locale was produced or is available. Finally it would add a UFT8 locale entry in /etc/default/dictd, possibly all using debconf. This would not, however, keep a problem from developing later if a locale was removed. Is this a common enough problem in Debian that a general solution needs to be developed? If anyone following this knows of similar situations, please let me know. Kirk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
