I strongly concur with what TP has to say. A clear line needs to be drawn into whether a term is technical or not.
Although one recommendation I might have would be with how let's say the spark docs in Databricks does it. For technical terms, they use the format: *<English Name> (<Different Language Translation>) * which preserves the original technical term and also provides a native language translation to it. For instance, this sentence in English docs: *Use the Parameters text box to provide all arguments and configurations necessary to run your * *task as a JSON array of strings.* Translates to this in Portuguese: *Use a caixa de texto Parameters (Parâmetros ) para fornecer todos os argumentos e configurações * *necessários para executar sua tarefa como um array de strings JSON* Doc ref: https://docs.databricks.com/aws/pt/jobs/spark-submit Although we do not want to translate literally everything, atleast "short forms" like DAGs, XComs, etc should be kept as-is imo. Thanks & Regards, Amogh Desai On Fri, May 23, 2025 at 2:32 AM Tzu-ping Chung <t...@astronomer.io.invalid> wrote: > 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 > >
