-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Twine strings format #6741
Comments
|
The issue you've reported needs to be addressed in the translate-toolkit. Please file the issue there, and include links to any relevant specifications about the formats (if applicable). |
This issue has been added to the backlog. It is not scheduled on the Weblate roadmap, but it eventually might be implemented. In case you need this feature soon, please consider helping or push it by funding the development. |
OK
OK
Good point. |
An alternative approach might be to use Weblate instead of Twine - stick with only one of the native formats and download the other one using an API (or manually, for example at https://hosted.weblate.org/projects/organicmaps/android/cs/#download). |
Is where any chance that implementation of this format will be accepted if somebody contribute it (and all other code standards met)? |
Yes, but before jumping on that, please consult the approach to take in Weblate – it is currently built around the expectation that every language has the own file (or set of files). |
I've created a tracker issue for multi-language files support: |
Describe the problem
My project uses a tool called twine. This tool uses ini-style text file as a source for localizations:
A tool generates localization for Android and iOS by using translated strings from the file:
Generated files don't lose metadata information from the source text file.
For example, android/res/values/strings.xml:
Describe the solution you'd like
Implement support for this format.
Describe alternatives you've considered
See discussion in #6346
We tried "2. Drop Twine and upload Android and iOS files directly", but found this approach uncomfortable.
Screenshots
No response
Additional context
#6346
The text was updated successfully, but these errors were encountered: