On Sat, May 27, 2006 at 04:00:23PM -0700, Thomas Bushnell BSG wrote: > I see. This deficiency should be clearly documented in the > dictionaries-common documentation.
Thanks, I will put this more clear in the policy document, > i18n bugs are sometimes hard, and require clever work, but they are > very important to Debian. > > And, you should start thinking about how to merge the strings for > internationalization. Perhaps the Debian internationalizing team can > help? Regardless, it's a real bug in dictionaries-common, so I'm > arranging for that to be apparent. We got help from people in the Debian internationalizing team for the "manual symlinks" entry, that is something to always be internationalized (this was #299541). However the dictionary names are somewhat different than the usual internationalization problem, so they are not as important as the rest of the strings, like "manual symlinks" entry or questions text, which are fully internationalized. Somebody installing a dictionary presumably knows the name of the language in that language, at least much more that is for other pieces of software. I however agree that is better if we can develop a system that allows even this. Sometime ago, I was thinking about a possible system for avoiding problems with non displayable characters, part of which might apply here, The process can be something like * Call debconf for the translated string * Call debconf for the untranslated string * Map translated values <=> untranslated * Get current default value * Feed debconf with the translation for the default value * Feed debconf with the translation for the full choices string * Ask question if needed * Get current default value (translated) * Map current default value translated to the untranslated * Feed debconf with the new default value (untranslated) but when I thought about this instead of translation transliteration was intended. Something equivalent should also be done for the select-default-* and update-default-* scripts. I however think this plays far too much debconf, and when I tried to do some actual coding I remember things being more complex, and I also found my preliminary code not robust enough. That means that unless I can prepare something rock solid, this problem will be somewhat low in my TODO list. In the meantime I will make sure that the debconf call for getting choices is done with the "C" locale, so any translation is ignored (do not worry, this will not affect the real question text, that will be fully internationalized, only the choices to make sure they are as now). If I come to something simpler and solid I will be happy to use it, in the meantime I am leaving this report open, for reference so others can read about the problems implied in working about this. Thanks for your feedback -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
