Problem
Sometimes when exporting my translation files, they still contain my original source string. It looks like some of my exported translation files fall back on the source language while some don't. What is the logic behind this?
Answer
Our fallback logic is based on utility. Most of our files do NOT fall back on the source language. This is to enable:
- Usage flexibility, better testing and validation for translation completion during development
- Have option to fall back to source language if needed
- Reduce file size - only want translated keys to save disk space and file transmit time
For other file formats that contain arrays (such as .yml or .json) or string types in which a nonplural and plural string but work together to display a key (.stringsdict), fallback is required to make sure the correct translation is displayed or that the file is valid.
See the full list of file formats and fallback support.
Comments
1 comment
This really doesn't work for us. We have our own fallback logic.
For example: nl-BE should fallback to nl first, then to en and only then to our base language, tlh-KL
Now, if a translator wants to override something in nl for nl-BE, he has to copy the entire nl file and adjust the changes. This really doesn't work well.
I think you should leave the fallback to the consumer of the api, or allow fallback configuration.
Please sign in to leave a comment.