On Tue, Feb 11, 2014 at 1:25 AM, Ofnuts wrote: > On 02/10/2014 03:01 PM, Joao S. O. Bueno wrote: >> >> I agree with the file-format, >> ad I don't think keeping the i18n's in file is a bad thing to do. >> >> The idea of having a file as a "pill" containing all the translations, >> and such seens much >> more tasty than having to distribute separated i18n resources when >> I publish, say, a color palette on my blog. > > > I doubt that you'll ever have all the translations. Do you speak chinese, > basque, irish? In my view, the "external" I18N is easier to handle for the > standard resources (resources are not modified by translations...) and > allows roll-your-own I18N when the author doesn't speak your language. I'm afraid we are arguing over technicalities :) Since swatches and gradients are both handled by a single file format in SwatchBooker, you could just have po-assets/LANG.po that would get the contents of .sbz files, and then another script would write the updated data back into the .sbz files. Or you could carry around .mo files in binary builds. My point is that right now this is not essential. We lived without i18n, and it's something we could decide later. There are ways to deal with this without even breaking the file format. But we cannot exactly live with 8bit raw RGB data in GEGL-based GIMP, and 2.10 is the milestone when this really ought to be solved. So what I'm saying is whether we have a general agreement that a) things have to change; b) SwatchBooker's file format is the way to go. If there's an agreement on a) and b), then it's simply a TODO material: http://wiki.gimp.org/index.php/Hacking:TODO. Which means we would be officially looking for contributors to work on that. Let's make the next step :) Alexandre _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
