Learn two different languages

[Jim8Knopf]

Hey guys,

I started learning the basics deck in english. Now I want to learn the extended version in english and German. What is the best way to do this? I don't care if any progress gets lost. It's not like I magically forget it just because it's not reflected in the stats.
I saw in another discussion that it should be possible. When I tried it just override the other language. I would love to have two different decks like UG-DE and UG-EN in a folder. But I'm open to suggestions and the best practices for that.
Many thanks in advance for everyone that took the time to read this.
JK

[aplaice]

(I'm assuming you have v5.3, though I believe that everything should also work for all recent versions (~v4.0+).)

Both parts of this (switching from Basic (EN) to Extended (EN) (with or without loss of progress)) and having UG-EN and UG-DE in parallel are possible.

Switching from Basic (EN) to Extended (EN)

Essentially:

https://github.com/anki-geo/ultimate-geography?tab=readme-ov-file#levelling-up-from-standard-to-extended-or-to-experimental

Without loss of progress

If, using CrowdAnki, you import the Extended English deck over the Basic English deck, you should see a "Change Note Type" dialog box. In the Cards section, set Change Flag - Country to: to "Flag - Country" (instead of "Country - Flag"), and set Change Map - Country to: to "Map - Country" (instead of "Flag - Country").

to

(Your progress will be kept for the cards that are in both of the "Basic" and "Extended" decks.

With loss of progress

Just remove the Basic English deck and import the Extended English one.

Have UG-EN and UG-DE in parallel

If, using CrowdAnki, you import the Extended German deck over the Extended English deck, then all of the German notes/cards should be imported without overwriting any of the English ones. However, everything will be combined into a single deck ("Ultimate Geography"), so English and German will be mixed up.

If you don't want everything combined:

1. Create a new deck (say "Ultimate Geography EN").
2. In the browse window (b), search for the cards in the pre-existing deck (using "deck:Ultimate Geography"), select all of them (Ctrl+Alt+a) and move them to the newly created deck (Ctrl+d and choose the new "Ultimate Geography EN" deck).
3. Import the Extended German deck. If you had previously imported the German deck, uncheck "Do Not Move Existing Cards". (The German notes should now end up in the old "Ultimate Geography" deck.)
4. Rename the "Ultimate Geography" deck (to, say, "Ultimate Geography DE").

(Note that just renaming your existing deck "Ultimate Geography" deck to "Ultimate Geography EN" (instead of steps 1 and 2) wouldn't help here.)

---

I hope this all works and helps!

[axelboc]

Maybe worth putting this last part in a new section in the README? We could add a "How to" section after "Upgrading" and move "Levelling up from standard to extended (or to experimental)" into it. This would give:

## Upgrading
### First upgrade after APKG import
### Keeping deck customisations
### Major version

## How to
### Level up from standard to extended (or to experimental)
### Install two languages in parallel

[aplaice]

@Jim8Knopf absolutely no pressure, but if/when you have the time, it'd be valuable if you could comment whether the description we're adding to the README (based on the above comment) makes sense or whether anything could be clearer. (It makes sense to me, but I don't know whether I'm not assuming something or jumping over important steps.)

(This is assuming that the above actually work!)

Edit: oops this was supposed to go under my previous comment! (I'll leave it as-is to avoid multiple pings...)

[Jim8Knopf]

They there. I tried your first recommended solution to import both in one deck because this seemed plausible to me and I hoped I'll be able to update both of them in the future. The import itself works perfectly and I don't know what I did wrong when I tried it myself. Now I have a practical problem.

I can't differentiate between the German and the English cards. An example:
Capital Berlin?
Do I answer now Germany (english solution) or
Deutschland (German solution).
I know that's a minor issue but I gave it a thought and have at least a suggestion.

I used the dividing line between answer and questions as an indicator for some other decks. If we had a language tag like for example UG::en and UG::de and so on we could use this to color the dividing line.
I did something similar also for another deck. If you think that's not a good solution I'll try it with two decks.

And by the way what is the best way to help with improving the language translation. I might not be the best but I saw a view line where english terms were used instead of the German translation.

[Jim8Knopf]

I used smithing like this to make the country variablised for some states I'm learning:

{{#Capital}}
  <div class="type"><span id="state">state</span> of <span id="country">Country</span></div>
  <div class="value value--top" id="value">?</div>

  <hr>

  <div class="type">Capital</div>
  <div class="value value--image value--front">{{Capital}}</div>
{{/Capital}}


<script>
  var tags = "{{Tags}}".split(" ");
  var countryTag = tags.filter(tag => tag.startsWith("UG::"));

  if (cuntryTag.length > 0) {
		cuntryTag.forEach(function(tag) {
			document.getElementById('country').innerHTML = tag.split("::")[1];
			document.getElementById('state').innerHTML = tag.split("::")[2];
    });
  } 
</script>

And I added a tag that looks like: UG:: Australia::State

I think we could use something similar to make the different languages different. I personally changed the color of the hr but I think it would be really helpful to change country, capital and co to the local language. Maybe a Tag like UG::Country::Capital::Flag::Map and for the German on than UG::Land::Hauptstadt::Flagge::Karte

Than this tag could be used to have the correct translation in the cards.
What do you think about something like that?

[aplaice]

Now I have a practical problem.
I can't differentiate between the German and the English cards.

Yes, that's currently a major reason to use two decks!

I used the dividing line between answer and questions as an indicator for some other decks. If we had a language tag like for example UG::en and UG::de and so on we could use this to color the dividing line.

I think it's a sensible solution for the case of multiple language versions, but I'm not sure if it's ideal for people who just have a single version (e.g. they'll wonder why the dividing line colour has changed) and I think that your suggestion here is definitely superior:

helpful to change country, capital and co to the local language.

Yes, this definitely! Your Tag implementation idea is interesting — it's relatively straightforward to put in place, since (in terms of technical implementation using BrainBrew) we'd only need:

1. A tags:de/tags:fr/... set of fields, with the current contents of tags copied into each, plus the new per-language tag.
2. Some javascript (like you suggest) to use the new tag to choose a set of per-language terms. (I think it'd be cleaner to store the per-language text in the javascript, since we'd ideally also like to translate terms like "Hint" or "Flag similar to:", and storing all that in the tag name would be messy.)

---

An alternative solution (which is what I've been planning for a very long time, but never got around to...) would be to have different note types for each language; for instance for Capital - Country.html for German we'd have:

Details

{{#Capital}}
  <div class="value value--top">?</div>

  <hr>

  <div class="type">Hauptstadt</div>
  <div class="value">{{Capital}}</div>
  {{#Capital hint}}<div class="info">Tipp: {{Capital hint}}</div>{{/Capital hint}}
{{/Capital}}

--

<div id=answer class="value value--top">{{Country}}</div>
{{#Country info}}<div class="info">{{Country info}}</div>{{/Country info}}

<hr>

<div class="type">Hauptstadt</div>
<div class="value">{{Capital}}</div>
{{#Capital hint}}<div class="info">Tipp: {{Capital hint}}</div>{{/Capital hint}}
{{#Capital info}}<div class="info">{{Capital info}}</div>{{/Capital info}}

This obviously becomes an N×M problem (N=6-ish templates × M languages), so I think it would be best to have the translated (non-English versions) generated from the English source versions using Mozilla's Fluent or maybe gettext (with the relevant translations stored in localisation/de.ftl or localisation/de.po etc.). (It might be useful to store the generated files in git, in say, src/note_models/templates/localised/, but I'm not 100% sure.)

With, say, fluent we'd ideally have something like (using data-l10n-id to annotate the elements to be translated):

HTML source of Capital - Country

{{#Capital}}
  <div class="value value--top">?</div>

  <hr>

  <div class="type" data-l10n-id="capital">Capital</div>
  <div class="value">{{Capital}}</div>
  {{#Capital hint}}<div class="info"><span data-l10n-id="hint">Hint</span>: {{Capital hint}}</div>{{/Capital hint}}
{{/Capital}}

--

<div id=answer class="value value--top">{{Country}}</div>
{{#Country info}}<div class="info">{{Country info}}</div>{{/Country info}}

<hr>

<div class="type">Capital</div>
<div class="value">{{Capital}}</div>
{{#Capital hint}}<div class="info"><span data-l10n-id="hint">Hint</span>: {{Capital hint}}</div>{{/Capital hint}}
{{#Capital info}}<div class="info">{{Capital info}}</div>{{/Capital info}}

and:

(in, say, localisation/de.ftl)

capital = Hauptstadt
hint = Tipp
...

etc. for the translation files.

---

AFAICT the pros of the tag/javascript solution are:

1. The changes to the brainbrew recipes would (I believe) be smaller.
2. We wouldn't need any new pre-processing/localisation generation steps or scripts.

AFAICT the pros of the separate note types are:

1. It's IMO cleaner for the end-users, since they just get simple, standard Anki (HTML) templates. (For instance, they don't need to wonder where the "Capital" string literal comes from.)

2. (Linked to 1) it's easier for the end-users to customise each language note type (e.g. they want their German notes to have a blue background — they can just change the German Ultimate Geography note type style CSS (which they're likely already familiar with), rather than playing around with if (LanguageFromTag() == "German") { document.getElementByID("...").style etc.})

   One con here is that applying changes to all language versions (for the end user (we, on the generation side would just use the same style.css)) becomes more onerous, since each language style would need to be changed/copy-pasted.

3. It's more of a "progressive enhancement" (since we're not relying on javascript it's near-guaranteed to work on all platforms and all old versions).