On Thu, Jan 17, 2008 at 09:37:05AM -0500, Paul Donohue <[EMAIL PROTECTED]> was heard to say: > 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).
The big problem I see is the impact on the workflow of the translators. Right now they can just edit a .po file in one place to translate the program, and in another place to translate the manpages/documentation. Adding a translated configuration file would add a third file they have to modify in a new location, and in a format they may not be familiar with. So my thought was that it would be more workable for them if I did some up-front work to create a .po file for section descriptions. On the other hand, all that works only in the default configuration, and we'd still need a way to translate sections when the default file has been modified. So maybe I just need to support a directory of section translations and let the translators deal with it. Probably they can just copy the default file and edit it appropriately to create a Aptitude::Sections::Descriptions::<langcode> configuration group. The only technical obstacle to that is that I need to add support for picking a configuration group based on the current locale. Although that requires reading all languages on start-up; maybe it would be better to have defined filenames and only read the one corresponding to the current language code > 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. Problem is that xgettext actually parses the file as, e.g., C or shell source. That's why I was speculating out loud about writing a shell script to generate the default file and extracting strings from it (xgettext calls are supported in shell scripts). Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
