They've already spent the money they could use to develop a translations toolkit on hiring Pinkertons 💀

Since the localization database is now in SQLite, it is even easier to localize the client to new languages.
The client checks integrity of its own files so the unofficial translation cannot modify original files.
Therefore the client could check for a file like e.g. Unofficial_Localization.mtga that has appropriate structure.

Proposal of structure:

Table: client_localization
Columns: Key, Bundle, plPL, czCZ, skSK, ...
Each row has the same key as Loc table in ClientLocalization db.

Table: languages
Columns: Key, Name
Each row has the key that indicates the column from client_localization table. Name is what should be displayed in client among the original languages.

Table: cards
Columns: LocId, Formatted, KnownTitleId, plPL, czCZ, skSK, ...
The same columns as in Localization table of CardDatabase db. Each row has appropriate translation.

This is the bare minimum that would allow for getting the client translated without the need to modify original files.

The more languages, the better.

I always enjoy seeing things written in another alphabet, and I'm sure it would do wonders for other countries to enjoy the game too.

Possible solution:
Use `*_extra.mtga` filename template for externally provided data, e.g. "data_cards_extra.mtga" and "loc_Internal_extra.mtga" etc. - those files would include translated strings for additional languages. The file "loc_Binary_extra.mtga" would contain those extra languages to be displayed inside the dropdown.

After client update, if extra languages would be discovered but without translations of strings added by the update, the client could display "Extra Translations Need Update" message and switch automatically back to English. If the client would provide template for updated file, that would be the sweetest icing on the cake :)

Extra feature: You could add Python interface to the client that would send events to a message bus. This way plugins could be developed to have better grip on what the client is doing without the need of full logs. Such interface could also have a `lock/release` mechanism. Say the client has been updated and the translation is out of sync. An external app listening to events could catch it and issue a "lock" on MTGA while trying to fetch updated translation and then "release" the game to continue booting. This way the process could be seamless.