Skip to content


My feedback

1 result found

  1. 20 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Minder#05606 commented  · 

    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.

    Minder#05606 supported this idea  · 
    An error occurred while saving the comment
    Minder#05606 commented  · 

    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.

    Minder#05606 shared this idea  · 

Feedback and Knowledge Base