Open bwiernik opened 4 years ago
That looks like a sound approach. Ideally, we would still allow a flat string approach as a simpler alternative if no multilingual data input is needed. So you could do:
publisher: Oxford University Press
Or:
publisher:
value: whatever
language: ar
language-alternate:
value: Transliteration of the publisher's Arabic name
language: ar-alc97
Another question will then be how these language alternates will be accessible in styles. A simple approach could be something like testing for a language attribute, like <if variable="title" language-alternate="de">
. (See https://github.com/citation-style-language/schema/issues/327#issuecomment-667008825)
The drawback of this is that it will make style coding more complicated than necessary. In the medium to long run (i.e. after 1.1) we should therefore consider adding (optional, modularized) features to simplify this. I could imagine three potential solutions:
New attributes on cs:style
, cs:bibliography
and cs:citation
A new element cs:multilingual
next to cs:citation
and cs:bibliography
.
<multilingual>
<titles>
<main/>
<alternate="en" prefix="[ " suffix="]"/>
</titles>
</multlingual>
This new cs:multilingual
element could even work a bit like locales. You'd have special multilingual configuration files that could be used together with regular styles.
Ideally, we would still allow a flat string approach as a simpler alternative if no multilingual data input is needed.
Yes, I think we would make the version on the CSL JSON explicitly denote that it is multilingual. That way, we can allow for normally-flat-string fields to be either flat-strings or objects. That gets around the contortions @fbennett needed to do to make CLSm JSON type-compatible with CSL JSON.
If CSL-ML JSON needs to be converted to vanilla CSL JSON, its the simple transformation that string-type variables have their value
extracted and the multilingual elements dropped.
There are a few "levels of involvement" here:
"Simple" handling
"Moderate" handling
cs:multilingual
above (which I think looks similar to the CSLm cs:alternative
). I would suggest here that it always goes to the locale/writing system of the bibliography environment its rendered in. Multiple locales is a further step (below)."Complex" handling
Just a quick note: biblatex is adding multiscript support: https://raw.githubusercontent.com/plk/biblatex/multiscript/doc/latex/biblatex/biblatex.tex
More information under \subsection{Multiscript Support}
(Don't know how exactly that will work. Need to digest that first...)
I just ran into this: https://www.ctan.org/pkg/biblatex-ms
Apparently, the biblatex folks have recently published the multiscript variant of biblatex. As of now, both versions seem to exist in parallel, the multiscript version is said to be slower and still a bit experimental, but it should eventually replace the current version.
Should be worthwhile looking into this...
We started to discuss multilingual data structures here: https://github.com/citation-style-language/schema/issues/327
In terms of data structures, my inclination is that storing multilingual variants should occur at the field-level. So, any field might be object with
value
,language
, andtranslated
elements. Thetranslated
element would be an array with elements holdingvalue
andlanguage
elements. Subordinate elements without alanguage
would inheritlanguage
from their parent. That would have 3 benefits:Originally posted by @bwiernik in https://github.com/citation-style-language/schema/issues/327#issuecomment-666385146