Sounds like a good idea, and it solves the non-English seedphrase issue while building on top of existing standards. It does introduce/keep some confusion, with non-English BIP39, but that confusion exists today as well. Fortunately non-English BIP39 support is marginal.
Some thoughts:
- Any description of this idea (no matter how succint) should mention that BIP39 has non-English language support, but it’s not widely implemented, and how it’s broken (no possibility for easy translation, incomplete).
- Having some of the same words as in the BIP39 lists is unfortunate, because a seedphrase can be composed of words that are all present in both lists, making it impossible to decide which scheme is used. (It would be an interesting exercise, to see how many combinations exists that produce a valid checksum in both schemes). I understand that the “direct translation of the English words” was a stronger design principle than the avoidance collisions with the BIP39 non-English lists.
- The main advantage of this scheme is that a non-English seedphrase can be relatively easily turned into the matching English seedphrase, by having access to and using the wordlists (non-English & English), and matching the words manually. This way the scheme does not rely on any implementation existing for the given language, after translation a standard English BIP-39 implementation will yield the same wallet. I see this as the biggest danger of BIP39, as someone with a non-English BIP39 seedphrase backup may be in trouble if supporting implementations disappear.
- Checksum. The checksum validity of a non-English seephrase can be determined before translation, as I understand. The entropy is derived from the word indices, and the checksum algorithm operates on the entropy. And obviously, the validity is preserved by translation (the indices are preserved).
- BIP. If the goal/expectation is that more than one wallet supports this scheme in an interoperable way, than this should be submitted as a BIP. It should also mandate that BIP39 non-English support should not be used, or at most as import-only (but never display/export in that format). After submission as a BIP draft the wordlists should not be changed (maybe new ones added).
- It would be interesting to gather prefix statistics on each wordlist: the most common 2-, 3-, and 4-letter prefixes and their frequency, the longest common prefix.
- I think the topic of diacritics/accented characters should be also covered, and (1) validate that no two words exist that are differentiated only by diacritics, and (2) propose that implementations also accept similar characters (e.g. ‘acido’ instead of ‘ácido’ (Spanish) or “eglenmis” instead “eğlenmiş” (Turkish)). Often input devices may lack the required characters.