i18n Applications

[rodvar]

Apply "KEY".i18n() technique to every text that is rendered on screen.

Language to be used needs to consider languages settings persisted in user profile

As per henrik's comment

All mobile only strings should end up in the mobile resource file, and then the generate task should be run to update the kotlin files (only engl. if no translations added). We should stick to a good naming convention to keep the strings well organized with first token as general section (e.g. offerbook) then the subsection (e.g. createOffer),... and we use camelCase in bisq 2 so we should stick to same style. Basically it should follow as close as possible the bisq 2 strings convention and existing keys (e.g. if we only add one new string to an area where bisq2 strings are used we should use the same key prefixes.

[rodvar]

@nostrbuddha this one is on the enhancements milestone for now. If we exhaust all other possibilities and we get stuck is a good candidate to bring to MVP since i18n is very desirable and we have the major effort done already

[nostrbuddha]

Understood. I will look at this, when I have nothing else to do.