blammit
commented
3 months ago Yes it's strange that we have CommonWords, since it leads to the use of the same text in different contexts, so in those cases we might as well be using qsTr() without translation ids. There are some attempts there to add context; for example, open_status has a value of "Open" with a hint of //: Status is 'open' to indicate it is not used as a verb, but with the amount of terms we have in CommonWords now, I am sure there are now many terms used in non-similar contexts.
I'm not sure it makes sense to use qsTrId() anymore, if the translation tooling does not make use of the translation ids. Plus, we don't have particularly useful translation ids in gui-v2, so they might as well be auto-generated.
gui-v2 translations are based on ids, but the translation tool POEditor doesn't support those. Either drop the use of translation ids (i.e. qsTrId() -> qsTr()) or migrate to a different translation tool/service. Currently there are 100+ translations unhandled by POEditor, because of these. The issue is not critical, because missing translations get autofilled during build, but highlights architectural issue that should be at some point sorted out.
Current code probably has hundred places where the issue is worked around by adding (often low-value) translation comment or by moving the translation to CommonWords. This leads to recurring meta work and/or translation issues that sneak in the releases.