Add localization support with JSON resources and Lokalize plugin enhancements#1618
Open
TheBlackBit wants to merge 1 commit intoopenwallet-foundation:mainfrom
Open
Add localization support with JSON resources and Lokalize plugin enhancements#1618TheBlackBit wants to merge 1 commit intoopenwallet-foundation:mainfrom
TheBlackBit wants to merge 1 commit intoopenwallet-foundation:mainfrom
Conversation
TheBlackBit
requested review from
VishnuSanal,
davidz25,
dzuluaga,
hanluOMH and
sorotokin
TheBlackBit
force-pushed
the
feat/doctypes-translation
branch
from
c941e8f to
48a886e
Compare
dzuluaga
reviewed
Mar 17, 2026
Contributor
dzuluaga
left a comment
dzuluaga
left a comment
There was a problem hiding this comment.
Nice work on the localization infrastructure! I have a few findings below — 2 bugs, 1 legal fix, and 1 design question.
multipaz-doctypes/src/iosMain/kotlin/org/multipaz/doctypes/localization/NativeLocale.ios.kt
Outdated
Show resolved
Hide resolved
...z-doctypes/src/androidMain/kotlin/org/multipaz/doctypes/localization/NativeLocale.android.kt
Show resolved
Hide resolved
multipaz-doctypes/src/commonMain/kotlin/org/multipaz/documenttype/knowntypes/DrivingLicense.kt
Show resolved
Hide resolved
| * First the attributes that the mDL and VC Credential Type have in common | ||
| */ | ||
| .addMdocAttribute( | ||
| DocumentAttributeType.String, |
Contributor
There was a problem hiding this comment.
Design question: getDocumentType() now calls LocalizedStrings.getString() ~80 times, and each call invokes NativeLocale.currentLocale() (which hits platform locale APIs). Previously these were static English strings.
A few implications worth considering:
- Performance: Every
getDocumentType()call does ~80 platform locale lookups + ~80 map lookups. If these are called frequently, it could add up. - Consistency: If the device locale changes between two calls to
getDocumentType(), you'd get different results. And sinceDrivingLicenseis anobject, callers might not expect the output to vary. - Singleton caching: If anyone caches the result of
getDocumentType(), they'll get strings frozen in whatever locale was active at cache time.
This may all be fine for the current use case — just flagging it as a behavioral change from the previous static-string approach.
Contributor
Author
There was a problem hiding this comment.
You’re right @dzuluaga that LocalizedStrings.getString() currently resolves NativeLocale.currentLocale() on every lookup, and getDocumentType() performs many lookups, so this introduces repeated locale/API calls and locale-dependent output across invocations. For current usage this is likely acceptable, but it’s still unnecessary overhead and less deterministic than before.
I’ll follow up with a small optimization: resolve locale once per getDocumentType() call and pass that locale through string lookups, so we avoid repeated platform locale reads while preserving dynamic localization behavior. I’ll hold off on DocumentType caching for now unless profiling shows rebuild cost is significant.
TheBlackBit
force-pushed
the
feat/doctypes-translation
branch
2 times, most recently
from
be00338 to
8973532
Compare
TheBlackBit
force-pushed
the
feat/doctypes-translation
branch
from
8973532 to
6b8cf47
Compare
VishnuSanal
approved these changes
Mar 17, 2026
davidz25
reviewed
Mar 18, 2026
multipaz-doctypes/src/commonMain/kotlin/org/multipaz/documenttype/knowntypes/DrivingLicense.kt
Outdated
Show resolved
Hide resolved
davidz25
reviewed
Mar 18, 2026
multipaz-doctypes/src/commonMain/kotlin/org/multipaz/doctypes/localization/LocalizedStrings.kt
Show resolved
Hide resolved
davidz25
reviewed
Mar 18, 2026
multipaz-doctypes/src/commonMain/kotlin/org/multipaz/documenttype/knowntypes/DrivingLicense.kt
Show resolved
Hide resolved
davidz25
reviewed
Mar 18, 2026
Contributor
|
This looks like a great start 🚀 - added a couple of comments! |
TheBlackBit
force-pushed
the
feat/doctypes-translation
branch
from
6b8cf47 to
d318b78
Compare
…kalize plugin
This commit introduces comprehensive localization support for the multipaz-doctypes
module and extends the Lokalize plugin with JSON resource format capabilities.
Key Changes:
1. Lokalize Plugin Enhancements:
- Added JSON resource format support alongside existing XML format
- New outputFormat configuration option (XML or JSON)
- Implemented JsonResourceScannerStrategy and JsonResourceWriterStrategy
- Added ResourceScannerStrategyFactory and ResourceWriterStrategyFactory for
pluggable format handling
- New generateMultipazStrings task for Kotlin code generation from JSON resources
- Supports code generation for platforms with unreliable file access (iOS)
- Added OutputFormat enum for format selection
2. Lokalize Convention Plugin:
- Created convention plugin for pre-configured defaults
- Applied common settings: defaultLocale="en", 22 target locales
- Configured Google Gemini as default LLM provider
3. Multipaz Doctypes Localization:
- Added StringKeys object with compile-time safe string constants
- Implemented LocalizedStrings for runtime string lookup
- Created NativeLocale expect/actual for platform-specific locale detection
- Added JSON translation files for 22 languages:
Arabic, Czech, Danish, German, Greek, Spanish, French, Hebrew, Hindi,
Indonesian, Italian, Japanese, Korean, Dutch, Polish, Portuguese,
Russian, Thai, Turkish, Ukrainian, Vietnamese, Chinese (Simplified)
- Updated all document types (DrivingLicense, EUPersonalID, etc.) to use
localized strings for display names and descriptions
4. Build Configuration:
- Configured multipaz-doctypes to use JSON output format
- Set resourcesDir to src/commonMain/resources
- Integrated generateMultipazStrings for code generation
5. Testing:
- Added LocalizedStringsTest and NativeLocaleTest for commonTest
Updated README files to document the new JSON format and code generation features.
Signed-off-by: Ever Morales <ever.morales@koombea.com>
TheBlackBit
force-pushed
the
feat/doctypes-translation
branch
from
d318b78 to
3a9eacf
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1617
Summary
This PR introduces comprehensive localization support for the multipaz-doctypes module and extends the Lokalize plugin with JSON resource format capabilities.
Key Changes
Translation Instructions
For detailed steps on adding new documents and translations, refer to:
multipaz-doctypes/README.md - 4-step process for adding strings
build-logic/lokalize/README.md - Plugin configuration and usage
Test Plan
Run ./gradlew :multipaz-doctypes:lokalizeCheck to verify translations
Run ./gradlew :multipaz-doctypes:generateMultipazStrings to generate code
Build and test on Android, iOS, and JVM targets
Verify localized strings display correctly in sample app