I18n support with statically generated class #145
Conversation
|
solution for #137 |
Not working yet on ios. Processing of the file content need more work (manual linebreaks not detected yet) and testing.
FOr ios its still not working. several attempts are kept in commented out form...
Build fails as it seems it does not access the src dir with the generated class correctly.
Split files per language. Add UTF8 support
rodvar
force-pushed
the
i18n-support-with-statically-generated-class
branch
from
fce6afd to
83fc291
Compare
|
rebased to main |
There was a problem hiding this comment.
Brilliant work @HenrikJannsen
Just deleted some commented code, merging now.
| @@ -36,15 +37,15 @@ class ClientApplicationBootstrapFacade( | |||
| if (!trustedNodeService.isConnected()) { | |||
| try { | |||
| trustedNodeService.connect() | |||
| setState("Connected to Trusted Node") | |||
| setState("bootstrap.connectedToTrustedNode".i18n()) | |||
There was a problem hiding this comment.
@nostrbuddha for the MVP we are ok as we commited support for english-only initially, but right after we need to use this technique "KEY_STRING".i18n() for every text used in the app after this PR gets merged.
There was a problem hiding this 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.
I left it as one day when we spend more time on it to get it working with files generated to the build directory or even to use the property files in resources directly those gradle snippets might be useful. But its in the history anyway... |
haha yeah indeed that code sounded familiar.. its ok - we are good for now with this improvement |
Superseded #140 and #134
As using the generated file in the build directory still does not work on iOS, this PR writes the files into the source directory. Further it adds UTF8 support and splits the bundles per language as otherwise the build fails as the file got too large.