We have a plethora of things that need localized names, some of which are currently acs-objects, some of which are not.
Examples of things that are not acs-objects:
- category trees
- categories
- workflows and workflow tasks, roles, states
- portal elements (table portal_element_map)
Currently we have two mechanisms in place for this.
1) The categories package has separate tables for names of categories, keyed by category_id and locale. It then caches all of the localized names for efficiency. It has a duplicate for category trees.
2) Portal elements put a string of the form "#package-key.message-key#" in the pretty_name column, and then run this through a call to lang::util::localize to do the message key lookup.
The first has the drawback that you have to create an extra table plus the user interface to translate the names for each single thing you want to have localized names for.
The second has the drawback that you need to make sure you create the message key somehow, otherwise you get a nasty "MESSAGE KEY MISSING" string in your UI, and there's currently no way to provide the translation unless you happent to have admin privilege on acs-lang, which then enables you to translate the entire UI.
So neither solution is particularly appropriate, and we need to find a good solution for this.
I don't have a good solution, but my inclination is to go with something like what the category package does, but turn it into a generally applicable service, which can be used with anything.
The acs-lang data model actually already has the provisions to do this, with the lang_translate_columns table:
create table lang_translate_columns (
column_id integer primary key,
-- cant do references on user_tables cause oracle sucks
on_which_table varchar(50),
on_what_column varchar(50),
--
-- whether all entries in a column must be translated for the
-- site to function.
--
-- probably ultimately need something more sophisticated than
-- simply required_p
--
required_p boolean,
--
-- flag for whether to use the lang_translations table for content
-- or add a row in the on_which_table table with the translated content.
--
short_p boolean,
constraint ltc_u unique (on_which_table, on_what_column)
);
However, the 'lang_translations' table, which, it seems, is supposed to hold the actual translation, is mising.
Does anybody have any further information about this abandoned feature?
Opinions on how we should do this?
/Lars
