[pkg-discuss] Requirement for localized Categories from the List API

[Danek Duvall]

Shawn Walker wrote:

> For example, if one package has the localised category and another has
> the 'C' locale category (plain-text English I'm assuming), then you end
> up showing the same category twice in the packagemanager.
> 
> In other words:
> 
> pkgA
> set name=pkg.info_classification value=Development
> 
> pkgB
> set name=pkg.info_classification value=th:การวิจัยและพัฒนา

I don't think there's any way you can connect the two categories in this
particular case, so you have to show both.

If you have a large enough set of packages, which includes pkgA and pkgB,
then it may be possible to look at all the categories in all the locales
across those packages and find at least one which specifies both the C and
the Thai category for "Development" and use that information to coalesce
these two packages into the same category.

While that would be really nice, I don't think it's a requirement for now,
especially since I'd imagine that the vast majority of packages are going
to have categories specified in the C locale even if they have others as
well.

> Another thing we've never worked out is how our localisation is going to
> work.  Do we assume the current locale and then attempt to fallback from
> that to the 'C' locale (i.e. a set name= without a locale: prefix
> specified)?  Or is it a tiered system similar to what web browsers use?

I'd really like to see the tiered system.  As long as we're just talking
about set actions, then we can implement that pretty easily.  (Delivering
the "best" localized file is a bit trickier, but can be approximated with
faceting.)

Danek