The problem is, the line whether a term is technical or not is blurry at best.
Dag—sure XCom—yeah Asset—probably Variable—hmm Connection—hmm? Running—This has a specific meaning to Airflow tasks, but are you sure you don’t want to translate it? If you keep going down the slope, you end up with a mush of a translation. A line is needed to define what counts as technical. > On 23 May 2025, at 04:24, Aritra Basu <aritrabasu1...@gmail.com> wrote: > > Hmm, I think anything that's a technical term should remain. My thought > comes from the perspective of say, someone looks at the UI in German and > wants to know how to use a `datenbestand` they have no way of finding it in > the docs, if that makes sense? > -- > Regards, > Aritra Basu > > On Fri, 23 May 2025, 1:27 am Brent Bovenzi, <br...@astronomer.io.invalid> > wrote: > >> Actually, drop "Asset". It looks like it would be better UX to translate >> it. But it looks like "Pools" and "REST API" are harder to translate. >> >> On Thu, May 22, 2025 at 3:50 PM Brent Bovenzi <br...@astronomer.io> wrote: >> >>> Thanks Jens for starting this thread. >>> >>> I am very excited to introduce internationalization support to the >> Airflow >>> UI. Another thing we discussed and which everyone has been aligned on is >>> needing at least one regular committer being a CODEOWNER for a language >>> before accepting a new set of translations. >>> >>> I think we should separate what are core concepts which should never be >>> translated and which ones are more optional. For technical terms, it can >>> really vary language to language. >>> I would protect: >>> - Dag >>> - Asset >>> - Task >>> - XComs >>> >>> I'm ambivalent about things like Providers, Connections, Plugins and >>> Variables >>> >>> I would NOT protect the second word in each of: >>> - Dag Run >>> - Task Instance >>> - Asset Event >>> >>> On Thu, May 22, 2025 at 3:42 PM Jens Scheffler >> <j_scheff...@gmx.de.invalid> >>> wrote: >>> >>>> Hi Airflow-Devs! >>>> >>>> As I jumped on the stream to translate the UI and wanted to contribute >>>> German in https://github.com/apache/airflow/pull/50929 which is a next >>>> step after the enablement in >>>> https://github.com/apache/airflow/pull/50626 we came in the review into >>>> some UI / UX questions where we all are not sure what the best practice >>>> is. Is somebody around in devlist or knows somebody with good >>>> translation experience? >>>> >>>> When translating terms we basically came to the following questions >>>> seeking expertise: >>>> >>>> (1) We have some terms that relate to core concepts in Airflow, >>>> would/should we translate them? >>>> >>>> Examples where we are certain it makes sense NOT to translate: Dag, Uri >>>> >>>> But also a bit "gray zone" some terms can be well translated but then do >>>> not match to terms we might read in logs or code also when clicking >>>> through UI (and we for sure won't translate the terms in logs): Assets, >>>> Task, Provider, XCom, Variables, Connections >>>> >>>> (2) Should we define a common list of terms we never want to translate >>>> or would we rather decide this per language/region? >>>> >>>> I think this [DISCUSS] does not mean we need to block translation PRs >>>> (still we can re-work) but would be good to align on translation "rules" >>>> we should document for maintainers. >>>> >>>> Thanks, >>>> >>>> Jens >>>> >>>> P.S.: I am so much used to English it is really confusing to look at the >>>> UI in German language. Just looking "unusual". For me translated >>>> technical terms rather confuse me (Asset being translated to >>>> Datenbestand) but as power user I might not use German as I am so clear >>>> in the technical terms... but I am mainly wondering if a 100% >>>> translation will help or confuse beginners. >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org >>>> For additional commands, e-mail: dev-h...@airflow.apache.org >>>> >>>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org For additional commands, e-mail: dev-h...@airflow.apache.org
