Label Files

This project enhances Anymeta by adressing weaknesses in our current label system.

Developers, Editors and Project Managers have identified that the current label module leaves more to be desired.

This page is a space to wish and gripe about the current label system. It provides an outline and scope of what changes should be made. From these lists we provide a scope to the first phase of the project and direction of research.

Project code: mml44
Designs: not applicable
Budget: available soon
Time Recording: https://mediamatic.basecamphq.com/projects/5324605/time_entries
Trac:
Planning: August 2010/ September 2010

Developers (ernst) comments:

Current Features:

Each label has a set translations associated with it. A label has a set of translations associated with it. For every translation as short and a long string can be given.

Translations are associated with a context, this makes it possible to differentiate the label based on the kind or type that is being rendered. For example, the label RELATED is translated to "Related Things", for attachments however it is translated to "This image is displayed in:".

Translations for specific contexts can either be directly associated with a label, or a referring label can be specified.

Translation can either be manually edited in the website, or uploaded from a "label file". A label file is a csv file which specifies the translations for a label. In a label file it is possible to specify the translation for each context, or to specify referring label.

Problems:

Caching: The relevant translations are appended to each template before the template is cached. Changing a label does not invalidate the caches for these templates. Which means that the entire cache has to be flushed before the changes take effect.

Label files do not get imported on upgrades. When upgrading a site new labels have to be loaded by hand. Currently Eveline keeps track of a huge set of label files that need to be imported when upgrading. There is one aggregate file that is imported when a site is upgraded to the latest version of anymeta. When a site is not upgraded all the label files of the versions below the current one have to be uploaded.

Label files are overly complex. Because labels can be specified in several contexts, and have a long and a short text, the structure of these label files is much more complex than is to be expected.

Not necessarily a problem with label but still: Labels are used to store configuration. The width of images in list-items is stored in FIG_LI_WIDTH. This is probably done because this makes it relatively easy to differentiate the width of the image for different kinds and types. This is completely wrong however.

Only labels that are in templates are cached. When labels are used in code, the label has to be retrieved from the database every time the page is rendered. This gives significant overhead.

It is unclear where certain labels are used. The system store which templates render a specific label, but it is not necessarily clear when and where a certain template is shown. Usually only developers have this information.

It is not possible to share labels between sites. This might not be a feature we want, but there has to be a way to easily update all the labels in a group of sites that share the same translations.

Alternatives:

The current implementation is highly specific and custom for anymeta so other generic solutions to translating sites probably will not work.

Most software translation is done by using gettext. Although gettext also has some issues on php, it is fast does not need extra caching and is very stable and well tested. However it does not support long texts and specific contexts.

It seems that the complexity added by long texts and contexts is rarely used. Contexts are almost exclusively misused for configuration labels, which have to go away anyway. And long text are rarely set (it seems that this was also misused for configuration before, and th database is filled with old admin texts.

Possible improvements:

Make cache invalidation work. The current caching implementation is very efficient, but also very obscure. It would be difficult to fix caching for the current mechanism. A naive implementation where all the labels are stored in one cache key and retrieved before rendering might not be efficient enough though.

Create a mechanism where on a site upgrade (minor and major) all label files are re-imported. Make it possible to have project specific label files. This would eliminate the need for manually chancing the labels on upgrades.

The above solution would typically only import new labels and not override labels already defined. If there is a mechanism that specifies to specify that a certain label woudl would override existing labels, it would be possible to change the label in a group of site by putting these label files in the project folder of these sites.

Get rid of all the labels used for configuration. This probably means implementing some sort of fullback mechanism to make these settings dependent on the type/kind of the thing.

Editor Gripes/Wishes:

Project Managment Gripes/Wishes: