Store project metadata

[friedelwolff]

Currently we don't store any project metadata, and it would be useful where a string comes from (GNOME, KDE, or whatever). There is no existing place in the schema for it at the moment.

[friedelwolff]

Some ideas I've had on this is a list of tags per target, so that a target can be annotated with tags that are relevant to it. Project or meta-project (KDE/GNOME) will allow us to do this, and also allow us to model the case of the same string coming from multiple projects.

[dwaynebailey]

(In reply to BZ-IMPORT::comment #1)

Some ideas I've had on this is a list of tags per target, so that a target
can be annotated with tags that are relevant to it. Project or meta-project
(KDE/GNOME) will allow us to do this, and also allow us to model the case of
the same string coming from multiple projects.

Would your proposal be to use tags for everything? How would you create special purpose tags that related to linking a project to e.g. GNOME.

Would that call for a tag like this project:GNOME

I favour making this pretty flexible and not needing multiple columns for each type of meta data we would want to store.

It would be nice if Amagama was able to supply the image for the project if required.

[friedelwolff]

I think tags provide a way to do lots of things, yes. It won't be the right solution for all metadata, but it would provide help with several things I want to do. I also wanted to keep this pretty flexible, and that kind of namespacing of tags can work, although we need to check if there isn't a cleaner way in the database.

Although we can probably do images from amagama, I would prefer to do it from elsewhere. I believe that provides more advantages. Serving images complicates amagama slightly, and doesn't provide the user (for example virtaal/pootle) a way to use images that fit well in the visual theme (size, palette, etc.), or let's just say it doesn't encourage it :-)

[dwaynebailey]

(In reply to BZ-IMPORT::comment #3)

Although we can probably do images from amagama, I would prefer to do it
from elsewhere. I believe that provides more advantages. Serving images
complicates amagama slightly, and doesn't provide the user (for example
virtaal/pootle) a way to use images that fit well in the visual theme (size,
palette, etc.), or let's just say it doesn't encourage it :-)

If they are on amagama then you can get an image and it should be pretty lo-fi to match a tag to an image. It also means we can at least supply images that are clean and consistent. Consumers can always override what is provided.

[julen]

(In reply to BZ-IMPORT::comment #3)

Although we can probably do images from amagama, I would prefer to do it
from elsewhere. I believe that provides more advantages. Serving images
complicates amagama slightly, and doesn't provide the user (for example
virtaal/pootle) a way to use images that fit well in the visual theme (size,
palette, etc.), or let's just say it doesn't encourage it :-)

Images should be optional. If stored encoded in base64 this shouldn't complicate things.
Apart from that, something providing you with information X doesn't mean you are required to use that.

[friedelwolff]

(In reply to BZ-IMPORT::comment #5)

Images should be optional. If stored encoded in base64 this shouldn't
complicate things.

We could, but it makes the responses far larger, and we would serve these for each string. Our current JSON responses are very small (often below 400 bytes). Adding one 16x16 image like that could double the size of the response. This also happens with each request containing suggestions, not just the first one (since it isn't cached). We could just give a URL in the JSON response which would solve the caching problem.

Some advantages of serving files from amagama include:

• all clients having images available
• if we add a project, clients don't need to be upgraded
• allows clients to work with theoretical other amagama servers (not ours) with internal projects and icons.

Other disadvantages I see:

• we'll be limiting clients badly with available sizes or we'll really be complicating things for ourselves
• provided images can't fit into a palette

Apart from that, something providing you with information X doesn't mean you
are required to use that.

Of course. It would just be sad to add the base64 encoded data in the response and not use it. And I think most people will be too lazy to do something else :-)

[julen]

(In reply to BZ-IMPORT::comment #6)

(In reply to BZ-IMPORT::comment #5)

Images should be optional. If stored encoded in base64 this shouldn't
complicate things.

We could, but it makes the responses far larger, and we would serve these
for each string. Our current JSON responses are very small (often below 400
bytes). Adding one 16x16 image like that could double the size of the
response. This also happens with each request containing suggestions, not
just the first one (since it isn't cached). We could just give a URL in the
JSON response which would solve the caching problem.

You can add a parameter to the API request for getting images or not. As I said on my first sentece: optional.

[dwaynebailey]

(In reply to BZ-IMPORT::comment #6)

(In reply to BZ-IMPORT::comment #5)

Images should be optional. If stored encoded in base64 this shouldn't
complicate things.

We could, but it makes the responses far larger, and we would serve these
for each string. Our current JSON responses are very small (often below 400
bytes). Adding one 16x16 image like that could double the size of the
response. This also happens with each request containing suggestions, not
just the first one (since it isn't cached). We could just give a URL in the
JSON response which would solve the caching problem.

I wasn't thinking of loading this into the JSON, no please that is too heavy I think.

I was thinking of this, made-up JSON:

{ tags: "project:gnome" ...}

Client gets image from:
http://amagama.locamotion.org/images/tags/default/project:gnome.png

We could supply that URL to make it easier.

{ project-img: "http://..... .png" }

But that adds load per request which is supper redundant.

Rather we have a standard mapping ${amagama_server}/images/projects/${theme}/${tag}.png from which you can get an image.

So the images are always relative to the server you are querying. It allows you to request a theme so you could supply icons that work for Virtaal or Pootle, etc. And then the image is named after the tag i.e project:gnome.png

If there is no icon for the the requested theme then you fallback to the default theme, then to the server icon, then to a default amagama icon.

The client caches and images are served from a heavily cached setup of amagama. Using etags, long expiry times should make the load supper low. And any missing icons can most likely be handled by rewrite rules on the server.

OK the above is a lot of bits of work, but please I don't think the JSON needs to carry this at all.

[dwaynebailey]

Friedel raised the ideas of icon sizes. This probably is more important for Virtaal then Pootle. Not sure if we want to implement this but I think we can at least plan.

Two options:

1. Freedesktop style ...${theme}/${size}/${tag}.png

Where size is 24x24, 256x256, svg, etc. Not sure how they handle fallback, think one is defined as a default.

2. Filename ...${theme}/${tag}_${size}.png

Makes it easier to find the correct size.

[friedelwolff]

I guess we can start with a basic implementation just returning a name, and then see what we actually need from there on.

[transl8bzimport]

Originally posted by Chris Leonard:

(In reply to Friedel Wolff from BZ-IMPORT::comment #10)

I guess we can start with a basic implementation just returning a name, and
then see what we actually need from there on.

Being able to track an Amagama string back to it's origin is critical for improving Amagama entries by following the trail of breadcrumbs back to the origin and fixing bad translations.

[marcmittag]

@friedelwolff @unho @dwaynebailey Is something implemented in this regard?