After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 336225 - Support for common licenses in about dialog
Support for common licenses in about dialog
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.18.x
Other Linux
: Normal enhancement
: ---
Assigned To: gtk-bugs
gtk-bugs
: 471701 501074 (view as bug list)
Depends on:
Blocks: 330870 341070 346997
 
 
Reported: 2006-03-27 18:07 UTC by Behdad Esfahbod
Modified: 2011-04-19 15:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
initial patch (13.62 KB, patch)
2006-03-30 09:17 UTC, Behdad Esfahbod
needs-work Details | Review
about: Add :license-type property (11.50 KB, patch)
2010-07-11 18:45 UTC, Emmanuele Bassi (:ebassi)
none Details | Review
about: Add :license-type property (11.64 KB, patch)
2010-07-12 10:02 UTC, Emmanuele Bassi (:ebassi)
none Details | Review
about: Add :license-type property (13.32 KB, patch)
2010-07-12 13:24 UTC, Emmanuele Bassi (:ebassi)
none Details | Review

Description Behdad Esfahbod 2006-03-27 18:07:06 UTC
Currently each and every application in GNOME should mark the GPL/LGPL headers for translation, to show them in its about dialog.  This is a lot of extra work for translators.

The about dialog code can have a format-string translation of common lincese's headers and substitute the application name in there.  This can be enabled without any API.  If the license property is set to "GPL", substitute the GPL header, and similar.
Comment 1 Matthias Clasen 2006-03-27 21:16:33 UTC
There has been a vague plan to do this all along. 
It just needs a reasonable list of common licenses and a patch...
Comment 2 Behdad Esfahbod 2006-03-27 21:35:44 UTC
Just dropping ideas:

  - It the parser will ignore whitespace and lowercase the tag, and try to match against the list of available licenses.  They may look like 'GPL 2.0', 'GPL 2.1', 'GPL 2.1+', 'CC BY', things like that.

  - We can start by just GPL and LGPL and then later run a GNOME Goals session on cleaning up the about dialog in apps (it's in the wiki), and ask people to submit patches for their licenses that we don't support.

  - We may want to add a way to add exceptions to common licenses, without having to duplicate the translation again.  I'm not sure how to do this without adding new API.  Probably the parser should only parse and handle the first line of the license string.  So you can pass in a license string of "GPL2.1+\n\nAs an exception, you may to this and that...".

  - Support dual-licensing.
Comment 3 Matthias Clasen 2006-03-27 22:46:44 UTC
for dual-licensing, we might just say that people have to put in the full text,
since you likely want some text surrounding the licenses anyway, in that case.
Comment 4 Behdad Esfahbod 2006-03-28 01:08:28 UTC
It may also make sense to put all the license stuff in a separate pot-file or domain.
Comment 5 Behdad Esfahbod 2006-03-30 06:16:42 UTC
In fact it better go into a new property "license-name".
Comment 6 Behdad Esfahbod 2006-03-30 07:02:42 UTC
Ok, now that I'm down to patching, there's a little problem, that now the about dialog code should call gettext.  That's basically why I thought a separate property makes more sense.  So should I define a set_translation_domain too?
Comment 7 Behdad Esfahbod 2006-03-30 07:41:21 UTC
Oops.  Ignore my last comment.
Comment 8 Behdad Esfahbod 2006-03-30 09:17:42 UTC
Created attachment 62371 [details] [review]
initial patch

Ok, this is almost what I've been thinking.  I decided to not create a new translation domain, as at this point I don't think it's worth it.

The way I chose was to add a "license-name" property to GtkAboutDialog.  Then if the "license" property is set, that will be shown to the user.  Otherwise, if "license-name" is set, available licenses are searched to find the requested license and shown (after substituting the application name into them), finally if search fails, a simple string "%s is licensed under the %s license." is shown.
Comment 9 Behdad Esfahbod 2006-03-30 09:20:43 UTC
I also did some nasty tricks to keep the paragraphs of each license in one char * to reduce relocations, but make each paragraph translatable separately.  Not sure if the increased complexity is worth, although it's really a matter of two or three lines of code.
Comment 10 Matthias Clasen 2006-03-30 14:40:04 UTC
Hmm. 
If we decide to move the licenses to a separate translation domain, we
can just fix it to be gtk-2.0-license-texts or similar.

The price for using gettext in this way is that you have the full
text of each supported license in the .data section. And the price for 
making each paragraph a separate msgid is extra copying in _gtk_license_text_get_for_name.

I would be a bit happier if _gtk_license_text_get_for_name
could just do

  return gettext (name)

That way a) we only have the short keys in the .data section and
b) we don't do extra copies to reassemble the license from paragraphs.
Comment 11 Behdad Esfahbod 2006-03-30 22:40:28 UTC
Ok, makes sense, except that then we need English translations to have the licenses for English even, and worse, if a language doesn't translate them, we don't get the fallback English text.  If that's fine, the rest can be worked out, a separate domain, and handcrafted pot file works.
Comment 12 Matthias Clasen 2006-03-31 14:49:57 UTC
So, if you don't have a German translation for "GPL", you would get
"Dieses Programm steht unter der GPL Lizenz", ie instead of falling
back to the English text of the license, we fall back to a German text
citing the license by name". Not sure if that is better or worse.

You are right about the need for English translations.
Comment 13 Behdad Esfahbod 2006-04-01 02:16:50 UTC
Ok, what about deciding about the API for 2.10 and decide about the actualy license text implementation later?  For now it can simply show the short string.
Comment 14 Paolo Borelli 2006-04-01 12:16:04 UTC
(haven't read all the above discussion in detail, sorry)

Isn't it a bit more reasonable to load the licenses from files? Maybe mmapped...
Comment 15 Behdad Esfahbod 2006-04-01 18:38:02 UTC
There are not many files that gtk+ depends on at runtime..
Please do read the discussion.  Depending on gettext does solve most of the problem, but introduces a couple new ones.
Comment 16 Paolo Borelli 2006-04-01 19:02:20 UTC
Well, I now read all the comments in this bug and I don't see separate file mentioned... some of the things that imho should be considered:

 - the licences translations is somthing that affects many programs even not using gtk. We would probably want the same translation shared.
 - normal translators are probably not qualified to translate a license correctly: no offense intended, but license are legalese and the choice of each word must be considered in detail
 - keeping the licence text in the binary is not very nice and doesn't scale well for many licences

My idea is that we add a licence-file property and program would simply mark from translation the *filename* so that each translator could change "/usr/share/GPL" to "/usr/share/GPL.it" etc
Comment 17 Behdad Esfahbod 2006-04-01 19:33:18 UTC
The problem with the scheme you suggest is that it will not solve the problem at hand, since we don't have a common place for licenses installed.  Behnam had this idea of a small package distributing common licenses and all, but I guess we don't want to depend on another library/package either.  And having a license-file property is very fragile IMO.

Putting the licenses in a separate translation domain doesn't necessarily mean that gnome-i18n translators should translate them.  But another question now that you mention it, is that whether we want to use the GPL entirely or the 3-paragraph header only?
Comment 18 Behdad Esfahbod 2006-04-01 19:34:10 UTC
Again, if we agree on the public interface, we can sort out where to store licenses later.
Comment 19 Paolo Borelli 2006-04-01 19:49:52 UTC
Note thay with my scheme gtk would not depend on the new licenses package. The programs (e.g. gnome) would depend on it. And in the mean time they could still take advantage of a licence-file property since almost all of them already install the COPYING file.
Comment 20 Behdad Esfahbod 2006-04-01 20:11:18 UTC
Oh yeah?  Not any of the packages I know installs COPYING.  Distributions do.
Comment 21 Shaun McCance 2006-06-20 14:59:34 UTC
Note that a "license-file" property would be useful even to a program that doesn't use a "stock" license, as it wouldn't need to have the full text of its license in its source and in its .data section.  A "license-file" property would help everybody putting a license into a GtkAboutDialog.

A "license-file" property isn't mutually exclusive with a "license-name" of course, but it does seem overkill to do both.  Why not just add the more generally useful "license-file" and have GTK+ pass the buck on providing actual licenses?
Comment 22 Behdad Esfahbod 2006-06-20 19:02:40 UTC
The main problem with "license-file" is taht no package Iknow of currently installs its license file, while on the other hand every distro does that in its own place and way.  And that doesn't help with translations either.

If you have a concrete proposal about how the "license-file" property should work, I like to know.
Comment 23 Shaun McCance 2006-06-20 19:37:08 UTC
And very few programs are putting the license in the About dialog right now.  If I, as an application developer, decide to put a license in my About dialog, then I can install the license file if I need to.  It's certainly no more effort than putting the license text inline in my source code.

Sure, there is no package right now that installs common licenses.  But that's true no matter what API gets added to GTK+.

What I'm saying is that a "license-file" property is generally useful to a lot of people.  If I develop an application that's dual-licensed, I can't expect GTK+ (or whatever other package) to provide the full text of my dual-license arrangement.  But I could still use the "license-file" property if I install my license somewhere, and I think this is nicer than what I'd have to do with the "license" property.

It's much like GtkImage providing the "file" property along with the "image" property.  It saves you the effort of reading the file yourself in your application code.
Comment 24 Behdad Esfahbod 2006-06-20 20:15:56 UTC
Shaun, agreed.  But how does translation fit here?
Comment 25 Shaun McCance 2006-06-20 20:46:10 UTC
Well, having a "license-file" property would open the door for packages to install licenses in some common location, along with translations of those licenses.  Then translators could translate the file name.

Although that's going to present all sorts of problems:

1) Translators will end up translating the file name when they (or other translators) haven't translated the license in the appropriate package yet.
2) We won't be able to do _(DATADIR"/licences/GPL") because intltool won't be able to extract the string.  And we can't do _("/usr/share/licenses/GPL") either.  And even if we could do the first, app developers shouldn't necessarily use their own DATADIR.
3) We'll have issues of new license package versions not be installed in places where applications have translated file names.  Application developers are not going to watch which languages have translated the file name and update their dependancies accordingly for each release.

I'm just throwing ideas out here, but maybe GTK+ could do its own sort of multi-views content-negotiation-esque lookups.  So my application could request the license file "/usr/share/licenses/GPL", and if a user is running in German, GtkAboutDialog could look for "/usr/share/licenses/GPL.de" automatically.
Comment 26 Behdad Esfahbod 2006-06-20 21:12:41 UTC
With your last paragraph, I say you are back to license-name again.

Ok, lets do it like icons and docs are done.  You set a license-name like I propose above, and it is looked up in XDG_DATA_DIRS/gtk+/license/.  Gtk+ automatically falls back to English, like Yelp does for docs.  Gtk+ also ships with a default set of licenses, like gpl2, etc.  Apps shipping their own license can put the file in DATADIR/license/$appname (or create a symlink there) and pass $appname to about dialog.

Chpe also suggested opening the license in Yelp and let it handle translation lookup.  Not sure how feasible that is.
Comment 27 Christian Rose 2006-07-10 21:48:46 UTC
Asking translators to translate a file name is in my opinion way too error prone; most would not realize that it's afile name, or if they do what it's used for and how to translate it, and some few would probably be too optimistic and enter a different file name even though there is no translated file, causing weird runtime behavior when the file is to be looked up. Some others might ask the rightful question of "why do I have to translate this anyway, doesn't the software know if there is a translation present or not" etc.

I see this problem as two-fold:


1) Translation of license notices (as pointed out by Alexander Shopov in a recent thread on the gnome-i18n list):

"%s is free software; you can...\n"
"%s is distributed in the hope that it will be useful..."

and so on (where %s is the name of the application). This license notice blurb is extremely common and appears in handcrafted versions in many handcrafted about boxes already, and is driving translator nuts, both because they have to translate it over and over, and because slight changes in style and errors and typos in the text makes it not possible to reuse their translations.

But, and this is key; these notices are short. It should be possible to have some of these in GTK+, make it possible for application authors to optionally specify one of these with something like license = GPL_V2_OR_LATER; display_license_notice = true; and for gtk+ to use gettext() for the translations of these common notices.

For the GPL case, I think the recommendation from the FSF is to always include the English version, just in case, and make sure that the translated version says that its unofficial and that the English version is the normative one. So what you would actually mark for translation would be something like:

_("The following piece of text is an unofficial translation, which is provided for informational purposes only. The original English version which is provided below is to be used for all legal interpretations.\n\n%s is free software; you can redistribute it under..."), and so on, and then display the original license  notice below in English, without a gettext call.


2) Full license texts. Not many languages have translated versions of licenses like the GPL, and none of them are official. Also, the full license texts are lengthy. For these I do not see a problem with a file-based approach; gtk+ can include files with common licenses, and files with their unofficial translations, and do the lookup with a fallback to the English file, when the license property is set as described above.


So how about less common licenses? I think the only option here is to allow a license_file property which points to the application's license file, and make this property be mutually exclusive with the license property: you can use one or the other, but not both.
For translations, these are to be provided by the application, but the API should probably allow for some lookup; i.e. if we run in the "de" locale and the specified license file is "ourlicense.txt", then we use "ourlicense.de.txt" if it exists.
Comment 28 Alexander Shopov 2006-07-11 09:05:32 UTC
I would like to comment on the following:

1. Translation of licence notices (This is necessary):
I would even go as far as remove the %s parameter in the notices entirely. 
Thus these:
For example, these 
------------------------------------
Sound Juicer is free software; you can
Sound Juicer is distributed in the hope that it will be useful
GNU General Public License along with Sound Juicer

will become:
------------------------------------
This program is free software; you can
This program is distributed in the hope that it will be useful
GNU General Public License along with this program

I propose *no* %s parameters containing the name of the program - there are
languages that have genders, cases which will make the translations different
from program to program.

Use the generic "This program". We have the context, we know what "this" points
to.

The GPL v.2 advises the same: http://www.gnu.org/copyleft/gpl.html#TOC4

It will be easier for translators, strings will not get fuzzy when 
program names change etc., etc.

2. Translation of Licenses themselves - I am strictly against it. The official
versions are those that matter. Translations are no convenience whatsoever.
Epecially bad translations. There are far too many licenses out there! We
cannot provide translations to all of them.
We have to do some damage control here people!. For example - one of the
Bulgarian translation of the GPL v.2 the funny description of the program
"makes passes at compilers" became: "that makes holes in government sites"
http://bulgaria.sourceforge.net/prava/gplbg.html What you will get me with
License transations as a team leader is not a solution but another uphill
battle.

3. Get the low hanging fruit first. Do not think of a grand solution to life,
universe and everything else. My itch would have been scratched with a simple
policy to always use the same English originals and eradicate the small
differences. No need for API or GTK+ change.
Everyone is free to think their own different and incompatible license.
Everyone is free to make a double/triple/quadriple, etc. funny licensing scheme
depending on their mood or mixed up Moon-Venus caledendar. No need to think of
solution to this problem as it would backfire on us.
Comment 29 Behdad Esfahbod 2006-07-11 15:24:39 UTC
(In reply to comment #28)

> It will be easier for translators, strings will not get fuzzy when 
> program names change etc., etc.

That will not happen with "%s" either.

 
> 2. Translation of Licenses themselves - I am strictly against it. The official
> versions are those that matter. Translations are no convenience whatsoever.
> Epecially bad translations. There are far too many licenses out there! We
> cannot provide translations to all of them.

So?!  Some of us have quality translation of the major (say, GPL) licenses in our language, and we want to use it, because not all Persian speakers know English.


> We have to do some damage control here people!. For example - one of the
> Bulgarian translation of the GPL v.2 the funny description of the program
> "makes passes at compilers" became: "that makes holes in government sites"
> http://bulgaria.sourceforge.net/prava/gplbg.html What you will get me with
> License transations as a team leader is not a solution but another uphill
> battle.

So, fix the Bulgarian translation or reject it.  That's what you, the coordinator, are supposed to do.
 

> 3. Get the low hanging fruit first. Do not think of a grand solution to life,
> universe and everything else. My itch would have been scratched with a simple
> policy to always use the same English originals and eradicate the small
> differences. No need for API or GTK+ change.
> Everyone is free to think their own different and incompatible license.
> Everyone is free to make a double/triple/quadriple, etc. funny licensing scheme
> depending on their mood or mixed up Moon-Venus caledendar. No need to think of
> solution to this problem as it would backfire on us.

If you think we are doing unnecessary work and no Gtk+ API is needed, I don't understand why you're commenting here in the first place.
Comment 30 Behdad Esfahbod 2006-07-11 15:45:50 UTC
(In reply to comment #27)
> Asking translators to translate a file name is in my opinion way too error
> prone; most would not realize that it's afile name, or if they do what it's
> used for and how to translate it, and some few would probably be too optimistic
> and enter a different file name even though there is no translated file,
> causing weird runtime behavior when the file is to be looked up. Some others
> might ask the rightful question of "why do I have to translate this anyway,
> doesn't the software know if there is a translation present or not" etc.

Agreed.


> I see this problem as two-fold:
> 
> 
> 1) Translation of license notices (as pointed out by Alexander Shopov in a
> recent thread on the gnome-i18n list):
> 
> "%s is free software; you can...\n"
> "%s is distributed in the hope that it will be useful..."
> 
> and so on (where %s is the name of the application). This license notice blurb
> is extremely common and appears in handcrafted versions in many handcrafted
> about boxes already, and is driving translator nuts, both because they have to
> translate it over and over, and because slight changes in style and errors and
> typos in the text makes it not possible to reuse their translations.
> 
> But, and this is key; these notices are short. It should be possible to have
> some of these in GTK+, make it possible for application authors to optionally
> specify one of these with something like license = GPL_V2_OR_LATER;
> display_license_notice = true; and for gtk+ to use gettext() for the
> translations of these common notices.

This is in fact what my initial patch does, but mclasen prefers not to have even the short notices in the gtk+ binary, and that makes sense.


> For the GPL case, I think the recommendation from the FSF is to always include
> the English version, just in case, and make sure that the translated version
> says that its unofficial and that the English version is the normative one. So
> what you would actually mark for translation would be something like:
> 
> _("The following piece of text is an unofficial translation, which is provided
> for informational purposes only. The original English version which is provided
> below is to be used for all legal interpretations.\n\n%s is free software; you
> can redistribute it under..."), and so on, and then display the original
> license  notice below in English, without a gettext call.

Such a notice can be added by Gtk+ unconditionally.


> 2) Full license texts. Not many languages have translated versions of licenses
> like the GPL, and none of them are official. Also, the full license texts are
> lengthy. For these I do not see a problem with a file-based approach; gtk+ can
> include files with common licenses, and files with their unofficial
> translations, and do the lookup with a fallback to the English file, when the
> license property is set as described above.
> 
> 
> So how about less common licenses? I think the only option here is to allow a
> license_file property which points to the application's license file, and make
> this property be mutually exclusive with the license property: you can use one
> or the other, but not both.
> For translations, these are to be provided by the application, but the API
> should probably allow for some lookup; i.e. if we run in the "de" locale and
> the specified license file is "ourlicense.txt", then we use "ourlicense.de.txt"
> if it exists.

Yeah, file name lookup makes sense.  This is just like what yelp does for example.
Comment 31 Luis Menina 2007-05-07 20:26:53 UTC
Hi, is there some work in progress about this ? I would like to launch this GNOME Goal:
http://live.gnome.org/GnomeGoals/AboutDialog

I for now update the guidelines to include the full text of the license, as there's no patch commited.
Comment 32 Behdad Esfahbod 2007-05-07 20:45:53 UTC
I suggest holding that on.  Or go on with the GnomeGoal but don't provide full license text.  That's a huge waste of translator resources and we know that we will fix this issue someday in not so distant future...

To make progress we need someone like mclasen to wrap up the discussion/
Comment 33 Luis Menina 2007-05-21 02:49:36 UTC
Well, for me the copy/pasted license text should remain untranslated for now. But translated licenses in GtkAboutDialog will sure be a nice feature when this API will be finished.
Comment 34 Matthias Clasen 2007-05-22 15:29:42 UTC
ok, I find it a bit hard to distill an actual api proposal out of this discussion,
but I think there are two proposals here:

1) a license-name property, that would take values like "GPL", "GPLv2", "LGPL", 
 that would allow us to do smart things like looking for translations somewhere on the disk, or just put a translated boilerplate like "This program is under the FOO license", if the license text is not found on disk.

2) a license-file property that provides an escape hatch for custom licenses that you don't want to put into a string literal
Comment 35 Matthias Clasen 2007-05-24 20:35:01 UTC
So one research item for somebody here is to investigate what prior art there is in distros wrt to shipping licenses and translations in a central place.

ISTR Debian is already doing this. Where are they installing the licenses ?
How are the translations named ?
Comment 36 Behdad Esfahbod 2007-05-24 20:39:11 UTC
Behnam, can you answer Matthias's question in comment #35?
Comment 37 Yavor Doganov 2007-05-24 20:48:05 UTC
(In reply to comment #35)
> ISTR Debian is already doing this. Where are they installing the licenses ?

Not really.  Debian is shipping some of the most popular licenses in the package "base-files"; they reside in /usr/share/common-licenses/.  Currently included are GPL, LGPL, FDL, the Modified BSD license and the Artistic license.  Each package which is under one of this licenses just includes a short copyright notice in debian/copyright (that's /usr/share/doc/<package>/copyright when installed) that points to the full text of the license.

TTBOMK, no decision was taken regarding translations; I can't recall any recent discussions either.  Translations (of FSF licenses, at least) are always unofficial so I doubt that any action will be taken towards this idea.  It's too much work for little benefit.
Comment 38 Behdad Esfahbod 2007-05-24 20:51:34 UTC
So how are those exactly named?  A "find /usr/share/common-licenses" helps.
Comment 39 Yavor Doganov 2007-05-24 20:58:47 UTC
Sorry for not being clear.

yavor@patilan:~$ ls -l /usr/share/common-licenses/
общо 108
-rw-r--r-- 1 root root  6111 1996-12-16 04:58 Artistic
-rw-r--r-- 1 root root  1499 1999-08-26 15:06 BSD
lrwxrwxrwx 1 root root     8 2007-04-25 14:55 GFDL -> GFDL-1.2
-rw-r--r-- 1 root root 20403 2006-10-06 01:00 GFDL-1.2
lrwxrwxrwx 1 root root     5 2007-04-25 14:55 GPL -> GPL-2
-rw-r--r-- 1 root root 17987 2006-06-15 23:01 GPL-2
lrwxrwxrwx 1 root root     8 2007-04-25 14:55 LGPL -> LGPL-2.1
-rw-r--r-- 1 root root 25284 2006-04-28 00:32 LGPL-2
-rw-r--r-- 1 root root 26527 2005-06-16 17:32 LGPL-2.1

As you see, the generic abbreviations of the FSF licenses are symlinks to the latest version.  So if a package is "GPLv2 only", the link in debian/copyright points to /usr/share/common-licenses/GPL-2.  If it is "GPLv2 or later" it points to GPL, which will automatically point to GPL-3 once it's released (and the "base-files" package updated, of course).

Those are plain text files in US-ASCII.

P.S.  I'm not a Debian developer.
Comment 40 Danilo Segan 2007-05-25 06:40:17 UTC
gnome-desktop also provides GNU licenses (with translations, in DocBook format):
  /usr/share/gnome/help/gpl
  /usr/share/gnome/help/lgpl
  /usr/share/gnome/help/fdl

See http://svn.gnome.org/viewcvs/gnome-desktop/trunk/desktop-docs/ as well.

(Yeah, I know gnome-desktop is supposed to go away at some point, and Gtk+ won't depend on it, but I'm just saying... :)
Comment 41 Matthias Clasen 2007-06-01 13:59:53 UTC
Hmm, I don't think we are prepared to include a docbook parser in gtk...
Comment 42 Luis Menina 2007-08-07 09:31:05 UTC
Hi, is there something we can do to move things forward ? Could GTK+ ship some plain text files with the usual licences ? Or do we need a special library for this (sounds bad idea) ? Or should we just display the content of the COPYING file for the moment and forget about this ?
Comment 43 Emmanuele Bassi (:ebassi) 2007-09-04 14:28:23 UTC
*** Bug 471701 has been marked as a duplicate of this bug. ***
Comment 44 chuchiperriman 2007-11-25 01:25:00 UTC
Please, don't forget this issue!! I think is a good idea!!
Comment 45 Benoît Dejean 2007-12-02 18:24:57 UTC
*** Bug 501074 has been marked as a duplicate of this bug. ***
Comment 46 João Matos 2008-02-13 02:20:23 UTC
What's the status on this?
Comment 47 Gil Forcada 2009-02-10 01:48:32 UTC
Actually a year has passed and still is assigned ... assigned to what? :-/

Any follow up or discussion about it?
Comment 48 Behdad Esfahbod 2009-02-10 07:19:57 UTC
Lacking any sign of consensus on the design, I gave it up.  Anyone should feel free to pick it up again.
Comment 49 Javier Jardón (IRC: jjardon) 2010-02-10 20:52:33 UTC
Maybe useful see how KDE solves the problem: http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKAboutData.html
Comment 50 Luis Villa 2010-06-04 04:46:02 UTC
> So?!  Some of us have quality translation of the major (say, GPL) licenses in
> our language, and we want to use it, because not all Persian speakers know
> English.

If it wasn't done by a lawyer it isn't a quality translation, FWIW.
Comment 51 Behdad Esfahbod 2010-06-04 04:51:11 UTC
> If it wasn't done by a lawyer it isn't a quality translation, FWIW.

Never mind.  I was young and foolish... :)
Comment 52 Luis Villa 2010-06-04 05:10:30 UTC
Also, looking at the patch, I'd suggest using simplified text (as suggested by GPL2) rather than the full code header.

The license says:

"If the program does terminal interaction, make it output a short notice like this when it starts in an interactive mode:

    <program>  Copyright (C) <year>  <name of author>
    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
    This is free software, and you are welcome to redistribute it
    under certain conditions; type `show c' for details.

The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, your program's commands might be different; for a GUI interface, you would use an “about box”."

In the modern context, 'show w' and 'show c' might be links to the FSF's website (and the handful of official translations they have) rather than to local copies of the translated license.
Comment 53 Emmanuele Bassi (:ebassi) 2010-07-11 18:44:45 UTC
I've worked on a patch that implements what Luis suggests in comment 52.
Comment 54 Emmanuele Bassi (:ebassi) 2010-07-11 18:45:08 UTC
Created attachment 165692 [details] [review]
about: Add :license-type property

The :license-type property of GtkAboutDialog allows using a symbolic
enumeration value that will construct a placeholder license preamble
linking to a specific URL. This allows localization of the licensing
text without using a translation of the actual license, since it would
not be valid.
Comment 55 Takao Fujiwara 2010-07-12 04:16:27 UTC
Maybe typo?
-+      license_preamble = g_strdup_printf (gtk_license_preamble, url);
++      license_preamble = g_strdup_printf (_(gtk_license_preamble), url);
Comment 56 Emmanuele Bassi (:ebassi) 2010-07-12 09:45:39 UTC
(In reply to comment #55)
> Maybe typo?
> -+      license_preamble = g_strdup_printf (gtk_license_preamble, url);
> ++      license_preamble = g_strdup_printf (_(gtk_license_preamble), url);

yep, simply forgot the _().
Comment 57 Emmanuele Bassi (:ebassi) 2010-07-12 10:02:41 UTC
Created attachment 165715 [details] [review]
about: Add :license-type property

The :license-type property of GtkAboutDialog allows using a symbolic
enumeration value that will construct a placeholder license preamble
linking to a specific URL. This allows localization of the licensing
text without using a translation of the actual license, since it would
not be valid.
Comment 58 Matthias Clasen 2010-07-12 12:18:30 UTC
Review of attachment 165715 [details] [review]:

Looks good to me in general.

::: gtk/gtkaboutdialog.c
@@ +401,3 @@
+   * specified in the #GtkAboutDialog:website property.
+   *
+   * Setting this property overrides the #GtkAboutDialog:license property.

For properties which have a side-effect like this, I prefer to have a clearly discernible 'unset' state. Either make GTK_LICENSE_UNKNOWN not override the license-text, or add an UNSET state

@@ +2544,3 @@
+      g_string_append (str, priv->copyright);
+      g_string_append (str, "\n");
+      g_string_append_printf (str, _(gtk_license_preamble), url);

I think an explicit gettext call would be slightly clearer here.
Comment 59 Emmanuele Bassi (:ebassi) 2010-07-12 12:39:30 UTC
(In reply to comment #58)
> Review of attachment 165715 [details] [review]:
> 
> Looks good to me in general.
> 
> ::: gtk/gtkaboutdialog.c
> @@ +401,3 @@
> +   * specified in the #GtkAboutDialog:website property.
> +   *
> +   * Setting this property overrides the #GtkAboutDialog:license property.
> 
> For properties which have a side-effect like this, I prefer to have a clearly
> discernible 'unset' state. Either make GTK_LICENSE_UNKNOWN not override the
> license-text, or add an UNSET state

sounds good. GTK_LICENSE_CUSTOM might be more expressive; if you set the :license property, :license-type is set to 'custom', and if you set :license-type to 'custom' then you're supposed to be setting the :license text yourself.

> @@ +2544,3 @@
> +      g_string_append (str, priv->copyright);
> +      g_string_append (str, "\n");
> +      g_string_append_printf (str, _(gtk_license_preamble), url);
> 
> I think an explicit gettext call would be slightly clearer here.

okay.
Comment 60 Emmanuele Bassi (:ebassi) 2010-07-12 13:24:11 UTC
Created attachment 165737 [details] [review]
about: Add :license-type property

The :license-type property of GtkAboutDialog allows using a symbolic
enumeration value that will construct a placeholder license preamble
linking to a specific URL. This allows localization of the licensing
text without using a translation of the actual license, since it would
not be valid.
Comment 61 Behdad Esfahbod 2010-07-22 19:57:25 UTC
I still prefer a string license identifier instead of an enum...
Comment 62 Matthias Clasen 2010-08-02 21:13:34 UTC
Any strong reason to hold this up over enum vs string ?
Comment 63 Wouter Bolsterlee (uws) 2010-08-02 21:52:42 UTC
Referring to the licenses using strings leaves open the possibility to add new API to register custom system-wide licenses in the future (if desired, that is) without any API/ABI breaks, I think.
Comment 64 Emmanuele Bassi (:ebassi) 2010-08-02 22:23:08 UTC
extending an enumeration is not an API/ABI break. and if you need a custom license you can still use the :license property instead of the :license-type.

using string identifiers makes the code a little bit more awkward to implement, and to use.
Comment 65 Matthias Clasen 2010-08-10 04:02:08 UTC
lets go with the patch as is. Committed to master
Comment 66 Claudio Saavedra 2010-08-11 23:10:39 UTC
(In reply to comment #58)

> @@ +2544,3 @@
> +      g_string_append (str, priv->copyright);
> +      g_string_append (str, "\n");
> +      g_string_append_printf (str, _(gtk_license_preamble), url);

Is this assuming that copyright ends with a '\n' already? Because otherwise the copyright and the license preamble are in the same paragraph. Appending a double '\n' instead would make it look nicer.