Support non English article

[cccaballero]

Right now you can use translations in title and abstract for non English languages, but you can't write an article in a different language and translate the metadata to English (a common practice in journals from non English speaking countries)

[helenum]

I endorse this proposal :)

[michael]

We have recently discussed the option of implementing multiple-language articles as separate documents. So that you start with an original document (say english), a "translate" action would create a copy of the document and set a language property (e.g. spanish). Now as a translator you would just rewrite the sections you want to translate. For the others you keep the original text.

Pro:

• we would not need to develop specialised multi-language features (clutters the user interface, and requires specific features for each use-case, title translation, abstract translations, figure caption translations etc.)
• you could realise full translations of the article
• same user experience during translating as during editing the original article

Con:

• not using JATS translation features, may require journals to adapt their multi-lang publishing strategy

Improvement ideas:

• we could disable structured editing (so that you can only change content, but not remove paragaphs etc.) that would allow us to associate translations with the original document. E.g. orig.paragraph1.content -> transl.paragraph1.content
• unchanged (=untranslated) parts could be marked in the JATS, so on display you could either hide them, or grey them out etc.

What do you think? (also ping @gustavofonseca @fabiobatalha )?

[cccaballero]

Hi, in my opinion (and in the Latin American context), the main issue with the proposed approach is that repositories or databases like SciELO or Redalic are expecting translated JATS, mostly for metadata like title, keywords and abstract, so this approach will make texture useless for exporting content to those databases.

[obuchtala]

I want to emphasize and correct, that the idea we have discussed was about using <sub-article> in a way it is explained in the JATS spec: https://jats.nlm.nih.gov/archiving/tag-library/1.1/element/sub-article.html

I.e. every translation gets its own sub-article, and can 'override' as much as needed, even only front matter stuff such as title, sub-titles, abstracts, keywords, subjects etc. but potentially also body content.

[gustavofonseca]

I want to emphasize and correct, that the idea we have discussed was about using <sub-article> in a way it is explained in the JATS spec: https://jats.nlm.nih.gov/archiving/tag-library/1.1/element/sub-article.html

I.e. every translation gets its own sub-article, and can 'override' as much as needed, even only front matter stuff such as title, sub-titles, abstracts, keywords, subjects etc. but potentially also body content.

So, for instance, a translated abstract would be placed inside a sub-article, instead of in article/front/article-meta/trans-abstract, even if it is the only piece of translated data?

Maybe I'm ignoring something, but at first it sounds like a very elegant solution.

[obuchtala]

So, for instance, a translated abstract would be placed inside a sub-article, instead of in article/front/article-meta/trans-abstract, even if it is the only piece of translated data?

Maybe I'm ignoring something, but at first it sounds like a very elegant solution.

Correct. Obviously, for this example the proposal sounds a bit like taking a sledgehammer to crack a nut. But to us it seems utterly consistent across all use-cases for translations.

[fabiobatalha]

Technically I like this approach but it seems to be a huge change of paradigm once everybody is used to keep the translations in the elements designated to it (trans-title-group, trans-abstract, etc).

It will probably be a huge change for XML producers, journals and other data sources that want to interoperate using JATS. I believe Érudit can deal with this, once we are starting to work with JATS in our current production chain, so we are still open for changes of this magnitude.

[obuchtala]

It will probably be a huge change for XML producers, journals and other data sources that want to interoperate using JATS.

We could address this as part of the 'Compatibility' topic. @michael could you capture this as a requirement?

[michael]

@oliver---- @fabiobatalha added it here:

https://docs.google.com/document/d/1ZOjKrQZOndU9G12bVaXmFt56aWRW4kJSDjaMjcxSHSc/edit#heading=h.2jwddxpcza1d

[jobdiogenes]

Why not stay using the standard JatsXML attribute xml:lang, that are in almost every section?

I really like @michael UI proposal, the triple dots is a common UI, so users will understand fast. And could also add new features/actions in the future.

But for the point of view to deal to the translations of Texture Interface code. My suggest is to use PO POT formats.