Add Full Language Version

[ruin1990]

I found a way to make Full Language version.
Now a upload a demo for template use this JavaScript trick in our style.css.

Can we do this?
src\note_modelsreference with multi-language_support.diff in multi-language_support_files.zip

We can get Anki users' device local language with

let language = (navigator.browserLanguage || navigator.language).toLowerCase();

Then we can add all language versions to each card. Select the corresponding language to display through JavaScript.
Use ###Text### as markup for regular replacement
Maybe this time we can integrate the full language version?
Finally, I would like to ask if our language code will become complete, such as en-us, zh-cn?

I have used this automatic translation method in the floating button of my ClozeAdv template. Everyone can test it.

Or we can use this method to make the template full language first?
I think we can make a big deal

[aplaice]

Very interesting and clever approach! Thanks for the suggestion.

I'm not sure if we want to go this way, for a variety of reasons, but it's definitely worth thinking about/adapting.

Some comments:

1. I'm not too happy about the hack of having the JavaScript code in the style. It has the huge advantage that we don't have to duplicate the code in each of the six templates, but it feels ugly.

   Ideally, BrainBrew would have an option to concatenate files when generating templates. (Something of the form of "Capital - Country.html" = "Capital - Country (raw).html" + "script.js" with the same script.js used for all six templates. It could even be potentially made reversible, by including headers in the concatenated file (<!--- HERE BEGINS Capital - Country (raw).html --->).) Obviously, it'd be tricky to implement correctly and robustly.

   Ideally, ideally, Anki would have a dedicated JS code field (analogous to the front/back/style).

   (Aside: this is not about your suggestion, just about how Anki's code apparently functions) It's horrifying that the hack works — i.e. that Anki just apparently wraps the CSS in a style tag and includes that inline. 😱

2. The device language often may not be the same as the deck language. For instance, somebody might use their device in English, but want to study geography in their native language. Alternatively, somebody might want to learn country names in a foreign language. (After all, we now allow parallel installations.) The language might not be even be the same on all the devices of one person. Hence, there might be an unpredictable mismatch between the language of the headers and the content.

   I personally strongly dislike systems that try to be intelligent.

   An alternative might be to hard-code the language code of the deck, per language, somewhere in the code. This loses the advantage of not having to have different templates by language, though.

   Another alternative would be to parse the deck name (using {{Deck}} in the templates) and extract the language code from that. Unfortunately, this won't work for people who move their cards into a single unified deck.

3. From the point of view of the JS implementation, it might be neater to have the templates annotated with appropriate ids or other attributes (e.g. have <div id="capital" class="type">Capital</div> or maybe <div data-l10n-id="capital" class="type">Capital</div>) and then parse based on that, rather than doing a regex search and replace. (The flag similarity would need some extra <span>s.)

4. This doesn't feel like a "scalable" solution. (Embedding the translations in javascript code; doing the replacement at "run-time" etc.) (AUG probably won't need to "scale" much though :).)

[ruin1990]

Hmm, I think there might be another way to do it.
We add all language versions to each note's field, like

{"en":"sth","fr":"sth","zh":"某些内容"}

Then adapt the js code of the template according to the language selected by the user

We can use the project of anki-persistence, but the disadvantage is that every time the user learns, the language has to be manually configured. Just like a menu?

My current method is actually because I don't know how to embed the same piece of js into each html template through brain-brew. After all, the code is actually the same.

From the point of view of the JS implementation, it might be neater to have the templates annotated with appropriate ids or ?other attributes

I think it's great

On the other hand, there may indeed be situations where the language the user wants to use and the system language are inconsistent. But I guess we can also output the single language versions at the same time.

[aplaice]

I think the key point here is about localising the note templates (the phrases "Capital", "Capital info" etc. themselves), rather than the contents. AFAIU it being dynamic is an implementation detail.

We could have the note templates be translated by having different note types for each language (it's definitely supported by BrainBrew), but it'd make the "recipe" files more complicated.

We'd ideally also have to think about not duplicating the template HTML — i.e. the words "Capital", "Country", "Hint:" etc. should be translated, but the HTML "structure" should be generated from a single source.

[axelboc]

Riiight, I get it now, thanks for clarifying.