Hi, Im pretty sure this question is probably already asked but I searched and couldnt find it.
Basically AFAIK, suppose ur source language is en and u have locales de, de-AT. The german locales fallback to the source language.
Is there a way to specifiy the fallback priority to be like de-AT fallback to de and then en?
Currently we achieve this by downloading the translations and then merging them on our end.
Hi @blessanm86,
Thank you for your post.
I am not 100% sure Iâve completely understood your question, so could you please provide me with more details about what you would like to achieve?
If you would like to see de translations while translating content to de-AT, then this can easily be done by using the setting âShow source string in <target_locale>â. More information about this can be found in our documentation guide here.
Does the above answer your question? If not, then please let me know what I missed and I will be more than happy to provide further clarification 
Hi Nina,
I am referring to when u download the translations.
Like normally when you download de translations, you fallback the empty translations to the source language.
Does that explain the problem
ah, I see now. Thank you for clarifying that.
Unfortunately, filling the empty translations with another target language is not supported.
However, if you find this useful, you can get these strings empty instead via our API using the download mode âonlytranslatedâ. Please note that this is supported for specific file formats (the list can be found here)
Yes we already do that and do the merging on our end after we download all the locales. It would be a great feature to add on ur side
@nina Is there any news on this? It seems like a important feature for a Translation product.
Basically the logic would be: âfr-CAâ overwrites keys of âfrâ, which overwrites keys of âenâ. This would allow us to only put country specific keys for âfr-CAâ, and common french traductions in âfrâ. The âenâ fallback is to prevent empty strings if we are missing keys in âfrâ.
Hello Gab,
Thank you for following up on this request.
As I understand it, you are looking for a feature that, when you download a translation file, allows you to set untranslated strings to be filled up first with existing translations of these strings (in the same language but in a different language local), and if there is no other translation available, to fill them up with the source text. Please let me know if I have understood your request correctly or if there is any additional information you would like to provide. Iâll create a feature request in our product backlog, and if this feature is released in the future, Iâll let you know as soon as it is ready for you to use.
Additionally, you can enable the translation memory fill-up feature if you want to fill up untranslated strings (not only when downloading the translation file) with translations from similar locales. You can read more about it here.
- Sandy
Hi, here an example
There are 3 files:
en (default): { hi: âhiâ bye: âbyeâ, thanks: âthanksâ}
fr: { hi: âbonjourâ bye: âau revoirâ}
fr_CA: { hi: âbonjour eh!â}
Fetching fr_CA would result: { hi: âbonjour calice!â, bye: âau revoirâ, thanks: âthanksâ }
Merging the language file with the language_REGION file, so only region exception are inside fr_CA, all language strings that are not region specific could be only inside the âfrâ file. This would save useless copy/paste of string for all french regions.
Hello Gab,
I have created a new product improvement suggestion and added it to our backlog for review by our development team. Our team will evaluate the feasibility of implementing the feature and prioritize it based on its impact and value to our users.
We understand the importance of this feature to you and we will do our best to include it in our future releases. Once the feature is developed and added to the product, we will inform you promptly so that you can start using it.
Thank you again for your contribution to our product development. If you have any further questions or concerns, please do not hesitate to contact us.
- Sandy
Any news on your side? 
I did a mistake in the example (mixed âeh!â and âcalice!â), sorry about thatâŚ
Good example:
en (default): { hi: âhiâ bye: âbyeâ, thanks: âthanksâ}
fr: { hi: âbonjourâ bye: âau revoirâ}
fr_CA: { hi: âbonjour eh!â}
Fetching fr_CA would result: { hi: âbonjour eh!â, bye: âau revoirâ, thanks: âthanksâ }
Hello Gab,
Iâve included your request in our feature request records for the teamâs consideration in our roadmap. While I canât guarantee immediate implementation due to resource constraints, we appreciate your suggestion. I apologize for not resolving this for you now, but weâll certainly keep it in mind for future updates. Any developments will be communicated here.
- Sandy
+1 for this feature request, are there any updates? - also is there perhaps a way to use Transifex Missing Policy to achieve the same functionality?
Hello @Mozafar_Haider,
I am Antonis from the Transifex Customer Success team. I hope youâre well.
This feature hasnât been implemented yet, but it is on our radar. Weâll provide updates once we have more information.
If youâre using Transifex Native, then yes, it should be possible to implement a custom Missing Policy that gracefully falls back to the base locale instead of the source (if you requested a translation and the string is the same as the source, then fallback to the base locale).
Thereâs no specific example in our documentation, and Iâm not a developer, but the general gist of how this could be implemented could look something like this (using fr_CA and fr as examples):
import { tx } from '@transifex/native';
class LocaleFallbackPolicy {
handle(sourceString, localeCode) {
// If the requested locale is fr_CA and translation is missing,
// try to get the translation from fr instead
if (localeCode === 'fr_CA') {
const frTranslation = tx.translate(sourceString, { _context: '', _key: sourceString }, { locale: 'fr' });
// If fr translation exists and is different from source, use it
if (frTranslation && frTranslation !== sourceString) {
return frTranslation;
}
}
// Otherwise, return the source string (default behavior)
return sourceString;
}
}
tx.init({
missingPolicy: new LocaleFallbackPolicy()
});
Let me know if this helps.
Thanks Antonis for the prompt answer - I will give the policy a try (weâre not using Transifex native, but maybe we should).
One more question - does this feature âfillup from similar localesâ achieve the same result? are there any caveats?
Hey @Mozafar_Haider,
Fill-up from similar locales is a feature in the Growth plan that might be relevant to your use case.
It works by automatically filling translations from the base locale to fr_CA (assuming fr is already translated), then allowing you to modify those translations where they differ from the base.
You can achieve a similar result by downloading a translation file from the base locale and uploading it to the target locale. This approach is more manual but available on all plan types. Note that some file formats may need modification before being uploaded as translations for a different language code.
Both approaches let you provide French translations immediately, even if they donât match the specific locale exactly. You can then refine them for the target market and release updates as you go.
Thanks @Mylon - we have the growth plan, so we can turn on that option. Just want to confirm how two locales are deemed âsimilarâ - for example, in our context, we have Uzbek language with Cyrillic script (key is uz_UZ_Cyrl), and Uzbek with Latin script (key is uz_UZ_Latn) - would these be considered similar locales? and if yes, can we opt out form the fillup behaviour per locale?
Hello @Mozafar_Haider,
Generally, we consider locales to be similar if they share the same base code, although there are exceptions. I tested the two locales you shared (uz@Cyrl and uz@Latn in Transifex), and they appear to share translations even though the script is different.
If you enable this option in your workflow settings, you will be able to add languages to your exclusion list, which will avoid the issue of these two sharing translations. This allows you to share content from some locales of the same base language while keeping others separate.
Thanks @Mylon - that was all very helpful.
