[
http://jira.nuxeo.org/browse/NXP-3592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anahide Tchertchian updated NXP-3592:
-------------------------------------
Description:
====================
Multilingual Content
====================
Use cases
---------
- Users can create documents that are translations of other documents, only
for documents that support this feature.
- Available translation languages can be configured by document type or
configured for the whole application, for every document type supporting
this feature.
- Distinct documents are used for every translation, as they should be be
able to follow disctinct review processes, be published independantly,
have different access rights, etc...
- When a "translatable" document is created, the language field is
required, but it can be changed afterwards.
- At creation time, translations in other languages may be created
automatically in the same folder and documents linked. This can be useful
if the application wants to provide the document in the original version,
in case nobody took time to translate it.
- The initial document created is considered as the "master".
- It is possible to create a new translation from the master, or from any
other translation of this initial document.
- There is no restriction on the translation language: the master document
can have several translations in the same language (is this acceptable?).
- When creating a new translation or editing an existing one, it is possible
to select the master or another existing translation to display the fields
to translate on the same form (in view mode only). It is also possible to
chose to prefill the new document fields with the original values.
- (Improvement): display a field by field diff on display)
- It is not possible to remove a master document if translations are still
present in the platform (even if current user does not have enough rights
on them) (Improvement: maybe switch master).
- A flag is available on translation documents. Possible values are:
- not-started
- in-progress
- completed
- outdated
All values can be set manually, editing the document. When a translation
is created automatically from master, it is marked as
"not-started". "outdated" flag is set automatically when master document
is modified. "in progress" and "completed" flags are only set manually.
NB: "automatic" behaviour here is not part of the feature, it has to be
implemented by event listeners => provide events and implement specific
behaviour in listeners.
- Custom code can make queries depending on the current language to select
only documents translated in this language. This is where automatic
creation of documents (at initial creation) can also be useful in this
case: all documents will be available in all the supported languages even
if translations have not be done yet.
- TODO: need to decide what happens when creating a version of a translation
=> what master document is it the translation of? Current live one in
workspaces? Same when publishing a translation: is the published doc
marked as a translation of the workspace live doc?
- TODO: copy/paste: when copy/pasting a master or one of its translations,
the translation links are lost (is this acceptable?). The new translation
links will have to be specified manually.
- XXX need to define another use case for folders (complex prop here?) would
be disrupting to have different folders => maybe define a translation
type + configure how it applies to document types (use a facet).
Technical architecture
----------------------
- Documents that can be translated have to hold a specific schema named
"translation" with given fields:
- translation_flag (string)
- master (boolean)
The language can be stored in the dc:language property.
- A runtime component has to accept configurations stating :
- default languages supported globally
- default languages supported per document type
- translation links are held as relations in the relations graph.
- A translation service needs to have the given API:
- boolean isTranslatable(DocumentModel) => can rely on translation schema
if it's enough (a Facet if it's not)
- DocumentModel getMasterDocumentModel(DocumentModel) => returns the
master document model for this doc.
- DocumentModelList getSiblingTranslations(DocumentModel)
- DocumentModel createTranslationDocumentModel(DocumentModel initialDoc,
String language, boolean prefill)
created a new document model with same type than the intial one.
prefills dc:language field with given value, and prefills all other
schemas from given document model values if prefill is true.
- DocumentModel createTranslationDocument(DocumentModel initialDoc,
DocumentModel translatedDoc)
creates translatedDoc in the repository, with current document as
parent, and marks translated document as a translation of the initial
one. If the intial document is not a master, its master is resolved and
used.
Fails with TranslationException if:
- given docs are of different types.
- no master document can be found from the initial document.
- an adapter is defined on document model. It caches information about its
translations (master + other languages).
Summary: Provide a multilingual content mechanism (was: Provide a
content internationalization mechanism)
> Provide a multilingual content mechanism
> ----------------------------------------
>
> Key: NXP-3592
> URL: http://jira.nuxeo.org/browse/NXP-3592
> Project: Nuxeo Enterprise Platform
> Issue Type: New Feature
> Reporter: Anahide Tchertchian
> Assignee: Anahide Tchertchian
> Fix For: 5.2.x
>
>
> ====================
> Multilingual Content
> ====================
> Use cases
> ---------
> - Users can create documents that are translations of other documents, only
> for documents that support this feature.
> - Available translation languages can be configured by document type or
> configured for the whole application, for every document type supporting
> this feature.
> - Distinct documents are used for every translation, as they should be be
> able to follow disctinct review processes, be published independantly,
> have different access rights, etc...
> - When a "translatable" document is created, the language field is
> required, but it can be changed afterwards.
> - At creation time, translations in other languages may be created
> automatically in the same folder and documents linked. This can be useful
> if the application wants to provide the document in the original version,
> in case nobody took time to translate it.
> - The initial document created is considered as the "master".
> - It is possible to create a new translation from the master, or from any
> other translation of this initial document.
> - There is no restriction on the translation language: the master document
> can have several translations in the same language (is this acceptable?).
> - When creating a new translation or editing an existing one, it is possible
> to select the master or another existing translation to display the fields
> to translate on the same form (in view mode only). It is also possible to
> chose to prefill the new document fields with the original values.
> - (Improvement): display a field by field diff on display)
> - It is not possible to remove a master document if translations are still
> present in the platform (even if current user does not have enough rights
> on them) (Improvement: maybe switch master).
> - A flag is available on translation documents. Possible values are:
> - not-started
> - in-progress
> - completed
> - outdated
> All values can be set manually, editing the document. When a translation
> is created automatically from master, it is marked as
> "not-started". "outdated" flag is set automatically when master document
> is modified. "in progress" and "completed" flags are only set manually.
> NB: "automatic" behaviour here is not part of the feature, it has to be
> implemented by event listeners => provide events and implement specific
> behaviour in listeners.
> - Custom code can make queries depending on the current language to select
> only documents translated in this language. This is where automatic
> creation of documents (at initial creation) can also be useful in this
> case: all documents will be available in all the supported languages even
> if translations have not be done yet.
> - TODO: need to decide what happens when creating a version of a translation
> => what master document is it the translation of? Current live one in
> workspaces? Same when publishing a translation: is the published doc
> marked as a translation of the workspace live doc?
> - TODO: copy/paste: when copy/pasting a master or one of its translations,
> the translation links are lost (is this acceptable?). The new translation
> links will have to be specified manually.
> - XXX need to define another use case for folders (complex prop here?) would
> be disrupting to have different folders => maybe define a translation
> type + configure how it applies to document types (use a facet).
> Technical architecture
> ----------------------
> - Documents that can be translated have to hold a specific schema named
> "translation" with given fields:
> - translation_flag (string)
> - master (boolean)
> The language can be stored in the dc:language property.
> - A runtime component has to accept configurations stating :
> - default languages supported globally
> - default languages supported per document type
> - translation links are held as relations in the relations graph.
> - A translation service needs to have the given API:
> - boolean isTranslatable(DocumentModel) => can rely on translation schema
> if it's enough (a Facet if it's not)
> - DocumentModel getMasterDocumentModel(DocumentModel) => returns the
> master document model for this doc.
> - DocumentModelList getSiblingTranslations(DocumentModel)
> - DocumentModel createTranslationDocumentModel(DocumentModel initialDoc,
> String language, boolean prefill)
> created a new document model with same type than the intial one.
> prefills dc:language field with given value, and prefills all other
> schemas from given document model values if prefill is true.
> - DocumentModel createTranslationDocument(DocumentModel initialDoc,
> DocumentModel translatedDoc)
> creates translatedDoc in the repository, with current document as
> parent, and marks translated document as a translation of the initial
> one. If the intial document is not a master, its master is resolved and
> used.
> Fails with TranslationException if:
> - given docs are of different types.
> - no master document can be found from the initial document.
> - an adapter is defined on document model. It caches information about its
> translations (master + other languages).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.nuxeo.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
ECM-tickets mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm-tickets
