Translated::* tags [was: Re: Tags for region and translation status?]

[Enrico Zini]

On Mon, Feb 13, 2012 at 11:22:38AM +0100, Michael Vogt wrote:

> The other one (probably more controversial as this will clutter the
> Tags file a lot) is to include a translated::$lang tag when there is a
> translation for the app (or when more than e.g. 80% are
> translated). This would be useful to e.g. hide (or warn about)
> untranslated apps for the current users language. I'm not 100%
> convinced about this one myself as it will potentially increase the
> size of the tags quite a bit (but I guess I should actually measure
> this). But I would really like the feature :)

This one is something that pops up every once in a while, but I haven't
found a good way to do it with tags.

These are the concerns that I see:

 - matching locales is more complicated than matching tags: if I have an
   it_CH locale, I very likely would want to get it_IT packages if no
   it_CH ones are available.

 - a lot of packages (like wget, for example) contain .mo files for all
   locales they support. Do you tag wget with 39 translated::* tags,
   with none, or with a useless "translated::lots"? All those options
   sound wrong to me.

I definitely like the idea of a feature in the package manager to show
available translations for the current locales, but I think that a
separate "Lang: <locale list>" control file header, with appropriate
matching code in package managers, possibly autogenerated with a
debhelper tool during package build, would be a more viable strategy.

For a package as simple as wget, such a header would look like this:

  Locale: ja sl et pt eu zh_CN zh_TW eo vi bg tr da sr fi sv nl fr id pt_BR en_GB hr el ru be ro it nb gl ca hu ga pl he lt uk cs sk es de

A Packages file full of those would be rather intimidating, I think.
Which suggests that this kind of information should probably be
extracted into some external metadata file. But at this point we are
rather far away from the scope of debtags.

Maybe I'm being just too pessimistic and failing to see some important
tradeoff, but that's all the thinking I've been able to give to this so
far.


Ciao,

Enrico

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enrico at enricozini.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20120214/27e1f86a/attachment.pgp>