Re: Fixing bug #330868 in a smart way

On 6/19/06, Paolo Maggi <paolo maggi polito it> wrote:
        I was giving a look to bug #330868 (Adding "License" button and dialog
to About dialog). It seems to me we are duplicating the same long
strings (mostly the GPL license) in most applications marking them for
translation in order to add a "License" button to the about dialog.

What about storing the most important open source licenses in a unique
repository in order to minimize string duplication and translators work?
I'm thinking to a special package like the one containing all the
languages name (the iso_639 module).

I would prefer if such functionality could be added to GTK+, at least
for the short License declarations (like "This program is free
software; you can redistribute it and/or
modify it under the terms..."), for the following reasons:

1) Most common widget and menu names are already defined (and
translated) in GTK+. A "License" button would be the same thing.

2) If there was an "add a license dialog to my app" API for developers
to use, it would make sense to allow a template for the short
declarations of most common licenses to be used.
If run in a non-English locale, also display a non-official
translation if it exists.

3) External dependencies that help translation (like the iso_639
module) are very useful, but developers are often not aware of it, and
for obvious reasons they try to avoid unnecessary dependencies, so in
practice, few applications make use of them.

I'm particularly interested in knowing what our fantastic i18n team
thinks about this problem. Is it a real problem for you or am I on
crack? Any volunteer to set up the module?

It is a real problem. I've lost track of how many times I have
manually copied the unofficial Swedish translation of the "This
program is free software; you can redistribute it and/or
modify it under the terms..." "This app is GPL"-style declaration
blurb into different applications.

Even more exciting since different applications format the texts
differently (with or without newlines and/or markup, different amount
of spacing, etc) and give different addresses to the FSF (the FSF
changed address at least once), so the number of variants in use is

A "do it once, do it right" convenience API for developers to use for
this would be a big plus, for both developers and translators.


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