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
4 comments
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.
The current approach doesn’t align with our needs. We have a custom fallback mechanism in place.
For instance, when using nl-BE, the fallback should first be to nl, then to en, and only as a last resort to our base language, tlh-KL.
However, if a translator wants to modify a specific entry for example [strands answer], they are required to copy the entire [ ] file and make adjustments manually. This process is not efficient and can lead to unnecessary duplication of content.
I believe it would be more effective to allow the fallback logic to be handled by the API consumer, or to provide the flexibility for fallback configuration. This would provide us with more control and prevent redundant work.
This answer explains why some of your exported translation files fall back on the source language while others don't.
The core logic is based on "utility," meaning it's designed to provide flexibility and efficiency. Here's a breakdown:
Most files do NOT fall back to the source language. This is generally the default behavior for several reasons:
Fallback IS required for certain file formats. This is where you see the source string appearing in your exported files. This requirement applies to formats that:
.ymlor.json)..stringsdict).In these cases, fallback is necessary to ensure:
In essence, if your translation files are in formats like
.yml,.json, or.stringsdict, you will likely see fallback to the source language due to the structural requirements of these formats. For most other file types, the system prioritizes not falling back to reduce file size and aid in development and testing.To get a complete picture, you would need to "See the full list of file formats and fallback support" as mentioned in the original answer. This list would specify exactly which file formats exhibit fallback behavior.
Cat Translator App
That's a helpful explanation regarding the word count discrepancy. For those dealing with legal research or public data in Georgia, conducting a detailed Georgia criminal lookup can offer additional insights alongside such administrative tools. Keeping both data accuracy and official processes in mind is always essential.
Please sign in to leave a comment.