A, -1, as long as there’s a translator with a sponsor to support, I don’t believe there’s a need to block a language. (Looking forward to something like Klingon 👀) B, -0, I like the discussion emphasizing the sponsor's responsibility. This should not be part of the release manager's responsibility.
Best, Wei > On Aug 30, 2025, at 10:21 PM, Jarek Potiuk <[email protected]> wrote: > > * 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >>> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>
