translations.md: What to do if a translation doesn't change anything?
reedy opened this issue · comments
I don't really speak any other languages, but I do notice differences between en-us and en-gb, and will translate into en-gb where I can...
Some projects have rules where if the "translated" message is equal, you don't translate it at all. The fallback chain etc will handle it. Some will translate it anyway for various reasons.
I don't see any advice either way on https://developers.home-assistant.io/docs/translations; and have seen some translsations on the lokalise platform that are translated and equal, and many that aren't translated at all (by choice? not got round to it?), but wouldn't actually change if they were translated.
Do we have a preferred way to go?
Should we be deleting equal translations that don't actually add any value?
If something is not translated, it will fall back to the source translation. So, I don't think it needs to be translated in such cases (it would only add more work to keep up).
But there are no specific rules around this.
Should we be deleting equal translations that don't actually add any value?
We can't do that.
../Frenck
If something is not translated, it will fall back to the source translation. So, I don't think it needs to be translated in such cases (it would only add more work to keep up).
But there are no specific rules around this.
Exactly!
As they add no value (but in theory add some maintenance burden), work exactly the same either way...
Can we add (I can propose a change) some wording suggesting people don't save these "translations" if there's no actual change?
Should we be deleting equal translations that don't actually add any value?
We can't do that.
Why not? As you say, they behave the same, and potentially become technical debt, there doesn't seem much reason to keep them around.
In other projects it is commonly done for this reason, as it adds complexity to workflows.
There's already messages in en-gb where mistakes (typos, grammar etc), have been carried forward, so then also have to be fixed when the source is changed, but add no other value. Rather than just allowing the fallback and update to do the job!
Why not?
Because it isn't supported by the tools we use.
Why not?
Because it isn't supported by the tools we use.
Ok, a technical restriction. That makes perfect sense, cheers :)
If deleting it in the translation UI will just cause it to be reimported from the code at a later date, that's obviously even more annoying than the current state!
Looking again as I was preparing a few tweaks to the docs...
- For a region specific translation, keys that will be the same as the base translation should be filled with
[VOID]. These will be replaced during our translation build process.
https://docs.lokalise.com/en/articles/1400511-lokalise-universal-placeholders
Does this only apply to en-gb vs en-us, or de against en too?
I don't see any messages (in en-gb) showing [VOID], but I'm not sure if at this point, messages marked as such get transferred and replaced with the literal text, and then inserted back in to the platform as the base translation... is the replacement bi-directional?
Should we be replacing verbatim translations with [VOID] instead, based on the rules above?
It looks like (at least) one user (someone I actually know AFK, amusingly; if his user name is the same over there as here, guessing it's likely as he's got HA activity in GitHub too. CC @danbishop hi ;P) is potentially just translating/copying the strings verbatim when they're newly imported...
Hah, hello @reedy it is indeed me.
I read this bit and decided that wasn't the way to go:
[VOID] – this placeholder simply means "translation is absent" and it will be exported as an empty string. However, it will be counted as "translated" on Lokalise. This placeholder can come in handy when you do not have a proper translation yet but you want to pretend that it is actually present.
When en-gb doesn't differ from en-us, it isn't that you don't have a proper translation, it just happens that the translation is the same.
I'm not sure how it makes any more work? If a string that had been translated to [VOID] changes, it needs to be rechecked anyway. The Lokalise interface makes it much easier to copy the source string (ctrl + insert) versus having to enter [VOID] each time.
Maybe I've missed something though?
Arguably, I'd suggest literally doing nothing at all in the first place if the translation is the same, and nothing is changed (because the fallback is used).
It's certainly what we do in other projects, and to the extent we will periodically delete so caled "equal translations" (though, in that case, there's added layers of complexity with what are essentially run time overrides.. which cause more fun).
In the case for HA though, we can't delete them; as per techincal reasons mentioned above.
Something something https://xkcd.com/927/ something something.
I guess, I also partially find the Lokalise interface to be.. lacking in someregards. But that's a different story.
This is obviously much more relevant in cases of en -> en-gb (and other similar variants) where the majority of the messages won't need changing, than say en -> de; though, I imagine there may be a minority of messages that wouldn't be translated to German, for example.
I'm not too bothered what really happens in practice, as long as it's properly documented and people are on the same page. There's clearly differences in opinion (which is fine) on how we should deal with it, both before a translation is added, and how we should potentially want to deal with those that exist.
If we don't actually want to be using [VOID], the documentation should probably reflect that. The Lokalise docs and our seem to differ somewhat.
Especially as it's expected usage as per Lokalise seems a little odd, as you quote.
This placeholder can come in handy when you do not have a proper translation yet but you want to pretend that it is actually present.
Feels more like gaming statistics than necessarily providing any real benefit (at least in a FLOSS-y contet). Or some weird handling for translation systems in apps that don't have any sort of fallback; whether simple or complex? Not that having it return the en message if a localised one doesn't exist should be difficult.. Or similarly, a build step that copies the en message into the language version, like HA does.
So it feels like someone mis-understanding the whole thing and resulting in a weird feature request ending up at Lokalise that they just implemented...
But considering l10n/i18n is mostly an afterthought for many projects (including, and possibly more likely, commercial ones), maybe I shouldn't be suprised. Certainly in other FLOSS-y projects, new hard coded English strings won't get through CR and merged; it should be minimal more effort to do it properly originally, than someone else retrofititng later.
From the current HA docs
For a region specific translation, keys that will be the same as the base translation should be filled with [VOID]. These will be replaced during our translation build process.
This makes more sense, and basically results in the fallback happening implicitly, without any action on the part of the translator if there is no need to make a change.
It's also not really "keys that will be the same" (as the key wouldn't ever change for a usage), it's the translation values of those keys... words are hards. "messages that will be the same" probably is better...
I'd also agree a couple of keystrokes to copy the source message is easier than typing (or pasting, unless there's some shortcut hidden) to paste [VOID]. But again, doing nothing (other than reading), and deciding no change is needed is less work.
I'd presume there's not much churn in many of the the source messages (whether minor or major changes; though I am causing a bit of that fixing issues in some of them I'm noticing as I go through), so in most cases, it wouldn't need much effort to view "recently updated (source) messages" to see what might need updating.
If a translation exists, which is identical to the "old" message, you end up doing a three way diff to work out if you need to update it (or pulling in the new source, and "re-translating), when in most cases, we could/should just use the updated fallback (becuase we were using the original message anyway), and it requires less effort as no editing is needed at all. Sure, some of those may introduce new words that cause the need to actually make a "translation".
I definitely don't think a goal of 100% translation in a variant is a good goal ;).
I definitely don't think a goal of 100% translation in a variant is a good goal ;).
That's why the en-gb translations for the android app were deleted, because there was "only a few percent". I asked for them to be added back and it's all working now, but personally given Lokalise's conflicting guidance and the fact that different sub projects (ios app, android app etc.) could treat fallbacks in a different way, I think copying the string works best.
In essence I wouldn't consider "variants" any different to another language, because no one else does when they're just skimming through and making decisions about all languages (e.g. let's delete this one, there's barely any translation). It's not something you'd convince most devs to care about.