Adding autonomous territories

[CoolTnt2]

Hello, I thought it could be great to add those territories:

• Vojvodina
• Chukotka
• Khanty-Mansi
• Nenets
• Yamalo-Nenets
• Nakhchivan
• Guangxi
• Inner Mongolia
• Ningxia
• Xinjiang
• Adjara
• Kurdistan Region
• Friuli Venezia Giulia
• Trentino-Alto Adige
• Aosta Valley
• Gagauzia
• Karakalpakstan
• Bangsamoro
• Nevis
• Autonomous Region of Príncipe
• Gorno-Badakhshan
• Ceuta
• Melilla

(All of them are gotten from the french Wikipedia pages https://fr.wikipedia.org/wiki/Autonomie_territoriale?oldformat=true and https://fr.wikipedia.org/wiki/R%C3%A9gion_autonome?oldformat=true)

[aplaice]

Thanks very much for the suggestion.

Unfortunately, I don't think we're likely to add these territories to the main deck, principally because there are too many of them, and most people won't be interested in them. Our current inclusion criteria of autonomous and dependent territories were (after long discussions...) chosen to be such that the relatively few such territories we include are those likely to be of greatest interest to users (largest, most populous, furthest away from the "parent country" (i.e. appear more distinct)).

However, in the long run, we would very much like to have a constellation of additional geography decks under anki-geo, and a "all autonomous territories" deck (as part of some larger deck or as a distinct deck of its own) is something we'd definitely want.

---

Please let us know if this is something you'd like to spearhead! (Otherwise, it'll probably happen eventually, but not soon...)

[CoolTnt2]

Thanks for the answer, Actually, yes I'd love to help you all develop an "all autonomous territories" deck to enrich this preexisting one. Just give me your guidelines and I'll take great pleasure in contributing to it.

[aplaice]

That's great to hear!

In that case, I'll create a repo for the new deck, under anki-geo!

Would you prefer the repo to be called something like "autonomous territories" or, say, "hardcore geography" or something else?

The main distinction is that in the first case we'd intend to just have all autonomous territories there, and then separate repos for each of mountains, lakes, smaller seas etc. (once we come to them!), while in the second, we'd (eventually, in the long run!) fit everything that's too extensive for the current main deck in this new deck.

We can easily migrate notes between decks, so this isn't at all set in stone. :)

[CoolTnt2]

I'm particularly interested in the "hardcore geography" one, it fits perfectly what I'd like to do. May you explain to me the way I should make my pull requests and the note style in this deck?

[aplaice]

I'm particularly interested in the "hardcore geography" one, it fits perfectly what I'd like to do.

That's great! :)

May you explain to me the way I should make my pull requests and the note style in this deck?

My apologies for the very late response! (It turned out that I've had (and have) even less time than I had thought :/). Ideally, we'd follow the structure, conventions and styles used in the main deck ("ultimate geography"), but if an alternative for any of these would be more convenient for you, we could also do that.

In terms of structure, we currently use BrainBrew to manage the decks, which allows us to keep the card/note contents in src/data as a set of flat CSV files.

The styling/formatting is in src/note_models and the media files (currently just images) are in src/media. Most of the rest of the files in the repository are "bureaucracy" needed to manage the building of the deck.

If this sounds sensible (and not too stifling/overly bureaucratic) to you, I can open a PR to hardcore_geography implementing a skeleton (without any actual content) along the lines of what we have here. You would then be able to easily add notes to src/data and maps/flags/etc/ to src/media.

---

As a heads up: I'll open an issue in ultimate_geography discussing how we might want to divide topics/material between ultimate_geography, hardcore_geography and any other decks. (@axelboc, @ohare93 and I have talked about this in the past, in several places, but we without reaching any conclusions.)

However, I definitely don't think that we need to finalise any of the decisions there before starting hardcore_geography:

1. Our tools allow us considerable flexibility in migrating notes between decks with relatively little wasted effort.
2. It might be better to make decisions on the overall structure of anki-geo after we've had some experience with more than one repo (there might be pain points or needed functionality that we haven't thought about).

[CoolTnt2]

Alright, it seems excellent to me! I made a PR in hardcore geography, copying and parsing most of the stuff in the ultimate geography repository. There is only one problem, the id in the note model .yaml file, I'm sure it has to be different but for the time being, I copied it too.

By doing that, I probably broke the BrainBrew compatibility and maybe other things too.

There may be some sort of an issue between the decks with the flag similarities and capital hints because these fields may be needed only with both of the decks.

[aplaice]

Thanks! That looks great!

I'd go with changing the note model UUID, but we can change our mind later.

There may be some sort of an issue between the decks with the flag similarities and capital hints because these fields may be needed only with both of the decks.

Ugh, yes, that's a good point!

[axelboc]

There may be some sort of an issue between the decks with the flag similarities and capital hints because these fields may be needed only with both of the decks.

I don't think we should worry about the main deck not hinting at the hardcore deck, as long as the hardcore deck does hint at the main deck when needed. The important is to be able to distinguish cards during reviews, and one card having a hint is enough in this case, in my opinion, since 1) there's clearly a hierarchy here (the main deck's card is more "significant" than the hardcore deck's card); 2) the main deck's card is likely to show up first (since most users would learn UG before HG).