Translated Model labels

[mdutoo]

(moved from #15 i18n)

First, note that it is probably even more useful to create country-specific versions of international Models that inherit from them, optionally with country-specific fields (with aliasedStorageNames) stored in international fields, with country-specific suffixes in the language of each country. For instance : geoci:city_0 with geoci:name field => geocifr:Commune_0 optionally with geocifr:nom field having aliasedStorageNames=geoci:name.

Now about translating international Model labels: this is done merely using translation / i18n of Models'Model stored as Datacore Resources (rather than in another prop file). What follows is therefore a use case of it.

• goal : allow service provider applications (& Model backoffice in Portal) to display translated Model names in ex. their web forms. However, the most common case if for applications to hardcode field names in their User Interface and not show fields that it does not know, so develop it only when it is required by use cases.
• How : to speed it up, gather translations from Models and cache them, to be done by clients or LATER Datacore ; up to LATER develop an alternate i18n storage for Models where translations are in separate collection(s), or better also as Datacore Resources (very appropriate, since not used by Datacore itself, and for Datacore allowing collaborative contribution). BUT translations should be addable on frozen published Model ("display"-kind of fields should be still modifiable even if others are frozen, possibly save for a "default" fixed language), so either allow it in Model workflow and gather and cache translations, or store translations in another collection and LATER aggregate them in Model results according to "view" setup. LATER OPT allow translations to be even shared or copied across Model versions.
• LATER dedicated fast API : Datacore's, or /dc/l/modelType (OPT or request over types) => { [ (modelType.)prop1(.prop2...) = translation ] in language provided in Accept-Language header (ex. value "en-US;q=0.8, fr-FR,fr;q=0.6,en;q=0.4") (Q or / and lang query parameter ?) see http://stackoverflow.com/questions/6544077/best-practice-regarding-rest-services-and-i18n ; POST is similar but checks compliance with model first and fails if unkown fields
• using it : (as Models themselves) will rarely change so will / should only rarely be called by applications and therefore rather heavily cached on client side.
• LATER OPT provide easy translation tools (translation completion indicators...) / web site (ex. Eclipse Babel-like).
• NB. Spring only provides stuff for webmvc so no use here http://stackoverflow.com/questions/18421788/spring-rest-api-and-i18n