potiuk commented on code in PR #55154:
URL: https://github.com/apache/airflow/pull/55154#discussion_r2320459868
##########
dev/i18n/check_translations_completeness.py:
##########
@@ -124,12 +124,7 @@ def expand_plural_keys(keys: set[str], lang: str) ->
set[str]:
def get_locale_files() -> list[LocaleFiles]:
return [
LocaleFiles(
- locale=locale_dir.name,
- files=[
- f.name
- for f in locale_dir.iterdir()
- if f.suffix == ".json" and f.name != "_freeze_exemptions.json"
- ],
Review Comment:
> +1 for jarek proposal, I like this workflow and it makes sense to 'move'
the target if we bypass the freeze. (it should be last resort, not something
that happens on a regular basis)
I don't want to "push" my approach and we can try it as it is now and see if
it's working - I think we have an example of it here:
https://github.com/apache/airflow/pull/53216#issuecomment-3245950307 and
https://github.com/apache/airflow/pull/54895/files
But honestly I am not convinced the `_freeze_exemption` is good. It seems
that such freeze will either hold on merging PRs (first PR above) or put
unnecessary burden and pressure on translations very late in the release
process when they might be not available or busy.
The "sliding" and _freeze_exemptions.json is somewhat complicated and
problematic because it will leave **very** little time for translators to
fill-in the gaps to be honest. If we deliberately merge it now and get all
translators in `#i18n` and get them informed about the new keys appearing, that
seems like translators will have more time to fill-inthe gaps.
We can try it this way for sure - I do not insist on merging this one, I
just feel it's unnecessary complicated and does not solve any problem.
The fact that translations have no 100% coverage is not a problem on it's
own, I think bigger problem is that translators do not **know** there is a new
translation to complete.
Deferring the merge to the "slide-in" time will still result with exactly
the same `<100%` coverage, the only effect it will have that ALL translators
will (possibly) learn about it very late before the release. And if no-one let
them know they might not even find it out before release which will results on
"rush" to fill in the gaps that might delay the release process. With those
"freeze exemptions" we are almost guaranteed that those added entries will not
be translated in a number of languages where people will have no time to fill
the gaps.
So I am not really sure what problem we are trying to solve by having the
`_freeze_exemptions` :). Also the TODO: comments left here and there in the
javascript code and the kinda complicated regexp expression to convert them
from "freeze" to normal - seems a bit brittle.
This also mean that whoever does the "slide-in" also takes the
responsibility to inform all translators and somehow 'make them complete it".
I think such "ad-hoc" information + check_translation_completeness showing
gaps immediatley + notification on slack that there is a new translation to
know that that things should be completed is a bit better.
But... If you want to try it this way @shahar1 -> feel free :)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
