Fixed #14976, #14975, #14973 - Translation strings aren't always working

[uberbrady]

Whew. This one is a doozy. Strap in.

So, Spatie's backup package - which is great, btw! - added translation strings for a lot of their notifications about backups.

Unfortunately, they used the Laravel/Symfony standard for how to name locales - such as 'en' instead of 'en-US'.

"Luckily" for us, we already had to create our own custom Translation service provider to handle pluralizations. Symfony, whose translation stuff Laravel uses, would only correctly figure out what language to pluralize in if locales were named en_US but not en-US. So we had written a shim to work around that.

Since that groundwork was already there, we were able to add another chunk of code to that to allow us to leverage Spatie's translations, without publishing those files. Any time you 'publish' a package's files, it always sucks, because once you do that you are stuck at that 'moment in time' forever.

The logic isn't that complicated - if you're trying to grab translation strings, and the 'key' you're looking up starts with backup:: - map the locale back to the "legacy" locales before you execute the lookup. Additionally, we need to change the 'fallback locale' - the mapping you get if there's no translation - to get a sensible default of US English. In Spatie's world, that's en, whereas in Snipe-IT's world, that's en-US.

This PR unpublishes the previously-published notification translation files, which will be good for us, as Spatie continues to flesh out their translations, we will be able to use them without making any changes on our side.

Additionally, this changes the default fallback-locale back to en-US - we had set it to en to try to pick up Spatie's default backup language, but this broke the rest of our own notifications, as 'en' isn't a language in Snipe-IT - en-US is.

Since we are reaching into the guts of the translation system, which we rely on pretty heavily, I felt like it was going to be a pretty good idea to get us a solid test-suite to make sure we weren't breaking anything else, and to make sure that we don't re-break this again, going forward.

[what-the-diff]

PR Summary

• Introduction of SnipeTranslator and $legacy_translation_namespaces
  A new element called $legacy_translation_namespaces was implemented into app/Services/SnipeTranslator.php. This, along with a newly added method named get, enhances the translation functionality of the application.

• Adjustment to Default Locale
  In config/app.php, we updated the default language from generic 'English' to the more specific 'en-US', providing a better localisation experience for users.

• Removal of Redundant Language Files
  A significant amount of language translation files related to backup notifications, listed in resources/lang/vendor/backup, were removed. This includes but not limited to Arabic, Bulgarian, Bengali, Czech, Danish, German, Spanish, Persian, Finnish, French, Hebrew, Hindi, Croatian, Indonesian, Italian, Japanese, Korean, Dutch, Norwegian, Polish, Portuguese (Brazilian and European), Romanian, Russian, Turkish, Ukrainian, Chinese (Simplified and Traditional).

• Addition of SnipeTranslator Tests and Translation Adjustment
  We have equipped the system with a new testing file SnipeTranslatorTest.php to verify the performance of translation strings in various languages. The test verification strings have been tweaked to correspond to the refreshed translations and to accommodate placeholders for variables.

• Inclusion of New Norwegian Translation
  A new translation string has been introduced for presenting 'no backups info' message in Norwegian. Meanwhile, tests were upgraded to match these recent changes in translations.

[snipe]

Yeah, this one was rough.

This wouldn't affect everyone, but if I have my brain wrapped around this one:

Strings should show up as missing for some users after the FALLBACK_APP_LOCALE was changed to en, since we - Snipe-IT - don't have that language directory. While the normal APP_LOCALE should have have been enough, I think this scenario exists when (and only when)

1. The APP_LOCALE was set to the older style two-letter abbreviation and was not updated AND
2. The user never set an override language in Admin > Localization AND
3. The user never set their own language preference at the user level.

If ALL THREE of these scenarios were true, strings would show up as missing because en isn't a language directory we have. If any ONE of these conditions were not true, the four-letter version would take over and everything would be fine.

#14976
#14975
#14973

@uberbrady did I get that right?

[uberbrady]

Yes, that's exactly correct - I can even come up with a few other scenarios that might have made it possible to create a situation where you have an invalid locale.

[snipe]

Do we maybe want to use the normal Laravel FALLBACK_APP_LOCALE env variable here? It seems like a potential footgun to invent our own override here.

[uberbrady]

No, I don't think so. The FALLBACK_APP_LOCALE is the fallback locale for Snipe-IT - and so it's going to be something like en-US or pt-PT. Whereas, in this code, we are dropping back to 'legacy' locales - en or pt or whatever. I could maybe see adding yet another (UGH) .env var to specify what 'legacy locale' you want to fall-back to when your main language isn't there - and since Snipe-IT is translated into many more languages than Spatie backup is, that's going to happen for sure.

I feel like 'hiding' the legacy locale situation from the users seems best, and picking US English as a fallback, when your language isn't there, is a pretty reasonable choice.

Some very weird situations could be created if we allow users to change this - Having a 'locale' of en-US and a 'legacy fallback locale' of pt for example would be extremely weird. Or if a user naively picked for their "legacy fallback locale" af - for Afrikaans - and it doesn't exist at all (in Spatie) - then they'd just get raw translation strings back. So I'd rather avoid those kinds of scenarios and stick to something that makes the most sense, and we know is going to work. It's also possible that Spatie could change their mind and start using the ISO-compliant localization names too in the future - and now we'd have this silly exposed environment variable that doesn't make sense anymore.

All that being said, I am not 100% sure of that decision, hence the TODO - I can be convinced.

[snipe]

I'm okay with this as-is I think. We can always look into it again if it becomes an issue.