[Proposal] JSON Translations fallback

[CristianLlanos]

Hi, everyone. First of all, I'd like to thank for all the amazing work! I really appreciate all the effort we all put into making our community one of the bests I know.

As for the proposal. I think it is a common case scenario to have translations like en.json and es.json. This works tremendously well (thanks @themsaid). However, It'd be even more amazingly useful if we can have the old fallback system for these translations, so we can cover regional variations.

For instance, we can have something like this:

echo __("ticket");
// If in Perú (Spanish speaking country), this will print "entrada"
// If in Colombia, this will print "boleta"

echo __("house");
// If in a Spanish speaking country (including Colombia), this will print "casa"

// es.json
{
    "ticket": "entrada",
    "house": "casa"
}

// es_co.json
{
    "ticket": "boleta"
}

I can help with this feature if we would consider adding it :) I would very much like to contribute as well. Thanks again.

[themsaid]

You can add as many locales as you want, I'm not sure what you're proposing.

[CristianLlanos]

Thanks for your reply, @themsaid. Following the example I gave. Let's say my current locale is es_co. If I wanted to print __("house"), the resulting string would be "house" with the current implementation of JSON translations. However, es_co is just a variation of es locale and it could print "casa" as a fallback translation using es.json. This is how key-based translations work in Laravel these days. Does this make sense?

[deleugpn]

No, it does not.

Are you talking about having fallback even for the default language?

[CristianLlanos]

I get it. I was just under the impression there was an intelligent fallback system for our key-based translations, but it was actually using a global fallback locale for all translations (see the service provider). Well, it would've been incredibly awesome to have such a system. So we could write all translations for a language in a single file like es.json and only care about the regional variations (dialect) in their proper files such as es_co.json or es_ar.json. Arranged in such a way that we would not have to repeat common translations for similar locales. Well, it's just a thought.

[deleugpn]

Let me see if I understood now. You want something like this:

{{__('House')}}

If the system is in English, it will just display House. If the system is in pt-BR, it would look for pt-BR.json. If there were no entrance in pt-BR.json for House, but pt.json exists and have "House: Casa", then it would fall from pt-BR.json to pt.json instead of falling to the English string?

[CristianLlanos]

That's exactly what I meant.

[deleugpn]

Chainnable Fallback. Sounds Weird. Really doubt Taylor would merge something like this. I kinda like it though.

[drbyte]

Not weird at all. It's what basic internationalization is about.

[sisve]

@deleugpn It's not weird at all. I've got my translations in the neutral locale sv (Swedish) and I want those to be used for any Swedish. sv_SE (Sweden), sv_FI(Finland) and sv_AX (Åland Island, belongs to Finland but they speak Swedish) should all get the neutral locale translations unless I've added a translation for the specific locale.

Fun thing; there's an AX Task Force that contacts companies that has trouble with Åland's custom region code to inform them about the issues...

[sisve]

@taylorotwell

Closing this without a comment make it unclear why it was closed. Is this already supported in Laravel? Do you consider it a bad idea?

[themsaid]

The problem is that we'll have to load an 2 extra language files if we can't find a translation, the file of sv.json and the file of the default fallback language en.json

I believe it'd be better to just copy sv.json into sv_FI.json and keep both in sync.

[sisve]

How is that an actual problem? I don't see any huge difference to io, cpu or memory resources.

Keep in mind that there are hundreds of valid language+region combinations. As an example, sv_US is a valid locale but perhaps not that common.

Would your answer change if I told you that there's at least 10 dialects for English according to https://www.andiamo.co.uk/resources/iso-language-codes (en-AU, en-BZ, en-CA, en-GB, en-IE, en-JM, en-NZ, en-TT, en-US, en-ZA), an 18 dialects of Spanish (es-AR, es-BO, es-CL, es-CO, es-CR, es-DO, es-EC, es-GT, es-HN, es-MX, es-NI, es-PA, es-PE, es-PR, es-PY, es-SV, es-UY, es-VE)?

The files should not be kept in perfect sync. It's fully possible that only a few phrases should be localized to a specific region, and the rest should default to the "general" language file.

[themsaid]

I think there's a way to define the fallback language dynamically, like if current locale isen_AU set default to en, so if translation can't be found in en_AU laravel will look in en.

[sisve]

That sounds like a relevant workaround. I guess it would be done when the LocaleUpdated event is fired. However, if it's this easy, why not include it in the framework? All we would need is to have support for an array of fallbacks, instead of just a string. Allow ['sv', 'en'] instead of just 'sv' .

Also, the setFallback method is not part of the Translator interface.

[themsaid]

That makes it sound more solid, will work on a PR. Thanks @sisve :)