Hmmm. I attempted to write the section descriptions to be compatible with unicode ... the idea being that translators could simply write their own copies of the default config file...
I don't know how successful I was (I didn't actually test it with unicode), and I'm not sure how elegant of a solution this is (as it would require swapping config files rather than simply changing the locale at runtime). Perhaps Aptitude::Sections::Descriptions could be extended to allow specification of descriptions in multiple languages, where the appropriate description is selected at runtime based on locale? I'm not deeply familiar with gettext, but from some quick reading of the docs, it looks like xgettext just needs some sort of identifier for translatable strings ... perhaps the description strings could be modified in some way that is benign from the config parser's perspective but marks the strings from xgettext's perspective? I haven't fully thought this through ... just kinda thinking out loud here. -Paul On Wed, Jan 16, 2008 at 05:51:31PM -0800, Daniel Burrows wrote: > On Fri, Jan 04, 2008 at 11:11:43AM -0500, Paul Donohue <[EMAIL PROTECTED]> > was heard to say: > > One more update... patch.topdir attached now uses the first entry > > listed in Aptitude::Sections::Top-Sections as a default if the top-level > > section is not recognized ... the previous patch was still using a > > hard-coded 'main' by default when the top-level section was not > > recognized. > > I like the idea of not hardcoding the set of known top-level sections, > but as I was looking over this I realized there's an issue I didn't even > think about earlier (or if I did I've forgotten). How will translators > deal with this? Right now I just use gettext to translate section > descriptions, but that won't work if the descriptions are drawn from an > external configuration file. > > It should be sufficient to arrange for these strings to be marked up by > xgettext, and to run gettext over them at runtime. Unfortunately, > xgettext will only process program source code -- but if the > configuration file was generated at runtime from a template by a shell > program, xgettext could be run on the shell script. It's a little gross > but should work just fine. > > Christian, is there a better way of handling this situation? > > Daniel > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
