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. Distributors of third party files are welcome to accept downstream contributions to the assets they create, or license their works in a way to allow for the creation of new versions, containing more languages. However, one option does not exclude the other - the use of the localization could be made in a way to use either built-in translations for colors/metadata or look for them in an external location if the former way defaults. (then one could have the best of both Worlds) js -><- On 9 February 2014 18:45, Ofnuts <ofnuts@xxxxxxxxxxx> wrote: > On 02/09/2014 07:55 PM, Alexandre Prokoudine wrote: >> >> Hi, >> >> I'm curious if we have a plan for assets in v2.10 and onwards now that >> 16/32 bit is possible. Color palettes and gradients are still based on >> raw 8bit RGB values, and pattern files are 8bit as well. >> >> FilmGIMP/Cinepaint "fixed" that in the past by converting everything >> to 16bit integer (afaik, integer), but I'm not sure if that's such a >> good idea. >> >> Some things to consider, in no particular order: >> >> - IMO, ideally, stock color palettes should be using a linear >> device-independent color space (some sort of LCh?); >> - it should be possible to use palettes that rely on arbitrary color >> models (RGB, LAB) to make paint vendors happy; >> - we still need to solve the i18n issue that was raised recently >> (non-translatable palettes/colors/etc. names). >> >> In my opinion, a sensible way to approach that would be using an >> already available, but somewhat forgotten file format devised by >> Olivier Berten during his work on SwatchBooker: >> >> http://selapa.net/swatchbooker/ >> >> To reiterate my earlier email to create@, the benefits of this file format >> are: >> >> - simple combination of XML + ZIP >> - (nearly) any color model + optional mapping to an embedded ICC profile >> - flat colors and gradients supported >> - spot colors supported >> - i18n-ized names of all metadata fields and color names >> >> There is no other file format that would provide the same set of >> features for us, free or non-free: >> >> http://www.selapa.net/swatches/colors/fileformats.php >> >> So the questions are: >> >> - Is changing the assets file format something we need to do for 2.10 >> (or maybe at all)? >> - Is the SwatchBooker's file format right for us? >> - do we actually have resources to make the switch? >> >> Opinions? >> > > Yes, that seems necessary. > > But I don't like much how i18n is handled in the SwatchBooker format. I > don't think the file should contain the names in multiple languages. Most > resources distributed outside of Gimp (DeviantArt, etc...) are by isolated > authors, and I would not expect their resources to be tagged in more than > two or three languages (English plus their native languages). I18N support > is done by users, and that would mean making a local version of the file to > display the file in the user's language. I would think a single name in the > file, remapped using a locale-dependent translation file (one in /usr/share > on in the user's profile) would let users rename resources more efficiently. > This method could also be used to display localized names for other > resources (brushes, patterns...). > > _______________________________________________ > 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 _______________________________________________ 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
