* A: I also think that we should **just** make sure we have no abuse. Having a willing translator (like Eloi) who we know and trust and who can take responsibility to make it "good" is enough - and doing just auto translation back to check for potential abuse should be enough. And sponsors should do it. * B. Absolutely - the sponsor(s) should take the burden in case of problems. Release Managers should mostly "mechanically" trigger things to start, but they should not need to follow up or chase anyone. Generally the role of Release Manager should focus on running the mechanics of the release, nothing more.
So I am C=A+B like Jens. With focus on sponsors being responsible to solve problems for their language when they happen. J. On Sat, Aug 30, 2025 at 10:56 AM Pierre Jeambrun <pierrejb...@gmail.com> wrote: > Thanks Shahar for formulating this. > > > A - As long as we agree to it and we have some process to prevent abuse > (those mentioned by Daniel or others) I don’t see any harm in accepting > any translation. > I think our current trusted parties / sponsors system is good for that if > we clarify what “trusted” means in that context. > > I think what Jens mentioned is interesting, in case of a sponsored owner, > maybe we should wait for another translator (also owner ideally) to double > check and verify correctness. This will avoid blindly merging sponsored > PRs. > > > B - I think we can keep the current flexibility, but make the translation > sponsor final responsible person for having the translation up to date. > > Meaning that if the owner does not fulfil the translation it’s up to their > sponsor to take actions (ping, ask community for additional help, do the > translation himself if applicable) > > This should offload release managers -> after the initial call for > incomplete translation is done, nothing more is expected from them, and > sponsors should take it from there in case owners are not answering. > > That should also incentivise sponsors to choose wisely who they are > sponsoring. > > On Sat 30 Aug 2025 at 00:24, Jens Scheffler <j_scheff...@gmx.de.invalid> > wrote: > > > Thanks Shahar to have the discussion here. > > > > I don't see issues with the current model we have. I'd propose to change > > the rules if we see _real_ issues. I am sure that one or the other > > language will potentially lose interest and we might need to remove it. > > But others will be added. I see this as a natural lifecycle and adding a > > language does not obey (compared to other features) that we need to keep > > a SemVer promise. Otherwise if people "miss" languages after removal > > they can engage and add them again. > > > > I think the current policy is good enough to ensure that translations > > are not flipping with every minor release. But the rules define and will > > have a general stability. > > > > Therefore my Opinion is like Shahar a A=-1 but B=-0.5 - I would not > > volunteer to be a sponsor for any strange guy coming along doing the > > first PR. But I did offer for persons I know personally and I trust (HU > > for Example Donat as well as Eloi which I met in Toronto and SF and > > looking forward meeting him in Seattle again - nice relation and I am > > proud that we have him (even if rare but) contributing). > > > > As for the fear of Daniel I would see the same but also here I'd only > > merge as sponsor if there is a profiliant native speaker available for > > proof reading. As translation sponsor I would not merge any PR from > > somebody I don't know or who never contributed. Engaged Translators > > should be the ones helping in the peer review. > > > > Therefore: I am C==A+B also looking forward for Catalan. And all other > > variants where people are engaged and there are users who benefit from > > it. I do not know Klingon (yet). > > > > Jens > > > > On 29.08.25 19:25, Daniel Standish wrote: > > > One thing is, we should probably ensure that there's an independent > > > reviewer (who speaks the language) .... *or* run it through a > translation > > > app.... before approving because, I can imagine a malicious actor > putting > > > undesirable messages in there. > > > > > > On Fri, Aug 29, 2025 at 8:27 AM Shahar Epstein <sha...@apache.org> > > wrote: > > > > > >> Following up the discussion in the thread(s) of accepting the Catalan > > >> language, I'd like to discuss the raised concerns here, in a separate > > >> thread. > > >> Concerns were raised regarding the acceptence criteria of the > following: > > >> A. Translations - do we want to apply specific conditions for what > > >> languages we accept? If so, what exactly and for what reason? > > >> B. Translation owners - do we want to ensure that translation owners > are > > >> active contributors (e.g., by specifying certain level of activity in > > the > > >> project)? > > >> Also, C. If we make changes in the policy according to the above > (A)+(B) > > >> that existing translation(s) (owners) do not comply with, do they > apply > > >> retrospectively? > > >> > > >> > > >> My personal opinions regarding the above: > > >> A. -1 - I think that as long as the language is standardized and > > there's at > > >> least one contibutor who's willing to maintain it - I don't see a good > > >> reason why to prevent it, > > >> even if it's regional or constructed language. > > >> To put it short - if Wikipedia could allow it (and does that > > >> succesfully), there's no reason that we won't (also, applying such > > >> conditions would put a barrier for the Klingon and en_pirate :) ). > > >> > > >> B. -0 We probably won't have anytime soon enough committers that speak > > all > > >> of the languages - so I think that we should allow some flexibility. > > That's > > >> why the sponsorship model was proposed in the first place. > > >> However, if we see it doesn't work in the next 2 released (i.e., > > sponsored > > >> translations remain unmaintained) - then we should consider to require > > some > > >> level of activity in the airflow repo. I don't think that we should > > take an > > >> immediate action about that, but If the community thinks that > otherwise > > - I > > >> won't be against. > > >> > > >> C. (A)+(B). I don't think that it's fair for contributors who worked > > hard > > >> on existing translations that we'll remove them due to a ruling that > has > > >> been taken after > > >> their work has been merged. If we decide to apply any > > restrictions, > > >> they should be applied only for languages that are merged after the > > voting > > >> (nontheless, > > >> the existing policy still applies - if they stop maintaining their > > >> translation, it might be removed unless there's someone else willing > to > > do > > >> it [accepting > > >> the new translation owner would be according to the up-to-date > > policy]). > > >> > > >> > > >> Finally, I would to clarify to avoid any misunderstanding (it's > written > > in > > >> the current policy) - sponsoring code owners (committers) are > > responsible > > >> to ensure that the translation owners fulfill their roles. > > >> If for any reason they don't, the code owners may look for someone > else > > to > > >> maintain the translation, or should raise a vote to remove it from the > > >> codebase. > > >> > > >> > > >> Shahar > > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > > For additional commands, e-mail: dev-h...@airflow.apache.org > > > > >
