Integrity of translation source texts and changes.

[dziugas1959]

This is an issue, which I was aware of, but did not think it would be on a dramatic scale, sadly, seeing nearly the entire source string being changed, caused me to question the integrity of these translations.

The fact that changed source text is unable to be flagged or be informed for the translator if it is still correct.
For example, „upnp“ has changed nearly of all of it's source texts.



The „insights“ function is not useful, since the only thing that it does is show „Changes committed“

The solution to this problem, would be to flag changed sources as: „Needs re-approval, due to the changes that were made“
If the translated text was at this day of this year and now the source is different, then it needs to be rechecked.
I have seen this done, though I am not a „Weblate“ expert to exactly know how it's done.

[dziugas1959]

+Delete the English language, there is no reason why I should be seeing „English (Developer)“ and „English“ with 99% parity.

[systemcrash]

You might be right to want to delete the English language, but there might be a load of historical original text there that isn't in "developer" yet.

[hnyman]

English (developer) is the original Luci source code. "English" is unnecessary addition, but people can add languages (like Lithuanian) by themselves. We can't easily prevent that.

Jow has prevented compiling English .ipk package, so the extra language is pretty harmless.

[dziugas1959]

Anyways, coming back to the original topic. In other translation projects, when a (source) string is changed, it marks all languages as „needs editing“, in case of „OpenWrt“ – some strings in „Weblate“ which were translated are completely different and there is NO SYSTEM set up in place to check for that. The longer this is kept, then nearly all of the translations at a later date will be incorrect, since edits are constant.

No one is going to manually check 9,925 strings for changes, which are not even reported in specifics.

[systemcrash]

The facility you speak of should be active, but I have no overview of weblate to judge - but since the repo here deals with raw edits, some PRs swap the origin string contents and the i18n pairs, maintaining consistency and not surfacing any kind of 'dirty' flag, since it is preferable to maintain a 95% accurate string vs (a change which then incurs) needing to i18n the whole string anew.

This is generally why I abhor really long strings explaining something. Break each sentence down into i18n units. The alternative? A whole paragraph, and then a single word changes later on...

In this specific case, someone came along and wanted to fix some of the upnp strings, but it got chaperoned by someone else: #6975 #6863 - do either of those affect these strings?

[dziugas1959]

„Upnp“ is not the only one, I can't exactly remember the places where I have seen them changed, but in short: texts that were this (long or short) became completely different.
From what I can see comparing other „Weblate“ projects is that „translation changed“ in source of „OpenWrt“ shows only one...
Which is factually incorrect, since we can see more (including luci-base).

In other projects, it shows multiple (mostly small edits) and every time that „translation changed“ is marked, then it is also marked for all other languages as „needs editing“.

P.S fix the „%GIT_VERSION%“ and „Žemaičių tarmė“ to „Žemaitiu kalba“

[systemcrash]

In other projects, it shows multiple (mostly small edits) and every time that „translation changed“ is marked, then it is also marked for all other languages as „needs editing“.

@hnyman any ideas?

P.S fix the „%GIT_VERSION%“ and „Žemaičių tarmė“ to „Žemaitiu kalba“

Fix it yourself :D

[dziugas1959]

Fix it yourself :D

Well I did? openwrt/firmware-selector-openwrt-org#19
Though, I can't fix the „OFS %GIT_VERSION%“, not in my ability at least.

[dziugas1959]

[systemcrash]

Should be fixed now. Thanks for the heads up.

[dziugas1959]