[Debtags-devel] The culture can of worms (was: Proposed Debtags goals for Etch)

[Enrico Zini]

[Note: I'm replying many mails at once, heavily reorganising the quote
 to put the various subtopics together, and splitting the result in
 different replies to start distinct subthreads.]

On Sun, Jul 17, 2005 at 09:42:38PM +0100, Justin B Rye wrote:
> Tag: culture::american
> Description: US localization
> Tag: culture::british
> Description: UK localization (or localisation)
> Tag: culture::canadian
> Description: Canadian localization
>  (I can imagine these labels may annoy, eg, francophone Canadians...
>  but at least they follow existing dictionary-package labelling
>  practice.  Unfortunately some don't distinguish; does that mean we
>  need ::english, or do those count by default as ::american, or
>  ::undef, or what?)

The culture facet is a huge can of worms.

It came to life to allow the query '!culture::* || culture::italian',
that will basically hide all culture-specific packages that are not
interesting to me.  However, I think that the goal is best served by
playing a bit better with the locales.

I chose not to use locale names to just stay out of political trouble:
my idea is that the name of the culture tag should be the same that the
locals use to describe themselves (translated to English to avoid the
need for full-utf8 tags).  Of course to have a culture tag there should
be at least one suitable package in the archive.

More shortcomings of the culture tag:

 - There is no easy mapping between the locale names and the culture
   tags.  This means that the package manager has no way to
   automatically hide 'uninteresting' packages without a configuration
   step.
 - There are too many tags to show them in a simple list, and there is
   no easy way to hierarchise them: would euskara be below spanish?
   palestine below israel?  ...and so on.  Alphabetical ordering, at
   least, gets us out of trouble.
 
So, culture is a facet that I would not want to stretch in any way.  I'd
just keep adding tags as long as packages arrive in the archive
supporting some other culture.


Given this context, let's go back to your question: if francophone
canadians have some special packages for them, we can add
culture::quebecois and everyone is happy.  But do we really need
american, british and canadian just for the ispell dictionaries?

Maybe british and canadian yes, since it appears that the default
language is US English.  So we could assume that everything is in US
English unless there's special localisation support for it.

It would make sense, but the idea gives me nausea: US English (yet often
a crappy version of it) could be the default language of untranslated
applications, but in no way the american culture is the default culture
in Debian.  The only packages I'd tag culture::american would be the
jargon file (that's US-specific geek culture, and /me kicks Eric Raymond
for marketing it as universal geek jargon!), nut-nutrition (it accesses
USDA nutritional data) and possibly filters, some US specific fortune
databases, the dict-gazeteer dictionary.

Uhm...

This would give us a clue on how to use those tags.  Do you think that
this view of them would stand?


----

> Tag: culture::geek
> Description: Hackerese localization
> 
>  (Only joking... though the more I think about it the more useful it
>  seems.  Oh, and we're also short of ::breton, gaelic, galician,
>  latin, latvian, lithuanian, manx, slovenian, swahili, swedish,
>  swissgerman and tagalog.  How'd we get ::faroese before ::swedish?)

About the culture::geek, that would get more in the field of
user-targeting.  I'd put it alongside with things like user::novice,
user::lawyer and so on, which are IMO best left to Custom Debian
Distributions.  Who are we to decide what's geeky anyway?  If someone
will make a Debian-GNU/Geek CDD, then they'll provide appropriate tags
for their users.

This at least is the reason why we still don't have easy/advanced tags.
The junior facet is a leftover from an experiment in turning the
'junior' task into tags, and I've been considering for a while to just
get rid of it.



Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico at enricozini.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20050723/68ae9c52/attachment.pgp