You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airflow.apache.org by Jens Scheffler <j_...@gmx.de.INVALID> on 2025/05/22 19:41:04 UTC
[DISCUSS] Special Terms in UI Translations?
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-unsubscribe@airflow.apache.org
For additional commands, e-mail: dev-help@airflow.apache.org
Re: [DISCUSS] Special Terms in UI Translations?
Posted by Wei Lee <we...@gmail.com>.
Thanks Jen for starting the thread and the discussion in the GitHub issue!
I'm not sure if all technical terms need to remain. (They probably could, but I don't think they need to.) These airflow concepts are borrowing the meaning of the original words. Otherwise, we could simply name Asset or Variable with random combinations of letters. (I'm not suggesting they need to be translated; I simply don't want to prevent them from being translated.)
I would suggest we only keep abbreviations like Dag, REST API, and URI, as they don’t have any meaning without being expanded. If we really want to translate them (I personally don't), we may need to create a term in that language. But that’s a discussion for another day.
I think Amogh's suggestions could address Aritra's concerns. The length of the text may vary depending on the language, which could make the UI look awkward. It should be up to the CODEOWNER to decide whether we should do it this way based on different cases. This is another reason why I think the decision to translate something could be based on language or region.
I believe our goal in adding this feature is to assist those who may not be as familiar or comfortable with English. This likely means that those of us participating in this dev mailing list are not the primary users of this feature. To some, the term "Asset" may seem like a random collection of letters, while "資源" holds meaning for some Mandarin speakers, as it conveys the concept of an asset. I think this is why we chose the term "Asset" initially. Even if users encounter the issue Aritra mentioned, changing the language back to English only takes a few clicks.
--—
The message becomes longer than I previously expected…
TLDR:
Thanks Jens for starting the discussion!
I believe we should only guard terms that have no meaning on their own (such as abbreviations) and let the owner of each language decide whether to translate other terms.
Best,
Wei
> On May 23, 2025, at 2:21 PM, Amogh Desai <am...@gmail.com> wrote:
>
> 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 <tp...@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 <ar...@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, <brent@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_...@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-unsubscribe@airflow.apache.org
>>>>>> For additional commands, e-mail: dev-help@airflow.apache.org
>>>>>>
>>>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
>> For additional commands, e-mail: dev-help@airflow.apache.org
>>
>>
Re: [DISCUSS] Special Terms in UI Translations?
Posted by Amogh Desai <am...@gmail.com>.
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 <tp...@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 <ar...@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, <brent@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_...@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-unsubscribe@airflow.apache.org
> >>>> For additional commands, e-mail: dev-help@airflow.apache.org
> >>>>
> >>>>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> For additional commands, e-mail: dev-help@airflow.apache.org
>
>
Re: [DISCUSS] Special Terms in UI Translations?
Posted by Tzu-ping Chung <tp...@astronomer.io.INVALID>.
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 <ar...@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_...@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-unsubscribe@airflow.apache.org
>>>> For additional commands, e-mail: dev-help@airflow.apache.org
>>>>
>>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
For additional commands, e-mail: dev-help@airflow.apache.org
Re: [DISCUSS] Special Terms in UI Translations?
Posted by Aritra Basu <ar...@gmail.com>.
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_...@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-unsubscribe@airflow.apache.org
> >> For additional commands, e-mail: dev-help@airflow.apache.org
> >>
> >>
>
Re: [DISCUSS] Special Terms in UI Translations?
Posted by Brent Bovenzi <br...@astronomer.io.INVALID>.
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_...@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-unsubscribe@airflow.apache.org
>> For additional commands, e-mail: dev-help@airflow.apache.org
>>
>>
Re: [DISCUSS] Special Terms in UI Translations?
Posted by Brent Bovenzi <br...@astronomer.io.INVALID>.
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_...@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-unsubscribe@airflow.apache.org
> For additional commands, e-mail: dev-help@airflow.apache.org
>
>