feat: add translation context for select options label

[FHenry]

Please provide enough information so that others can review your pull request:

On input type select the options value may need context for translation.
For example in Letter Head field align is a select as select Left/Right/....
in French/English
Left can be translated as "Left"(en) => "Parti"(fr) : the preterit of the verb "to leave"
Left can be translated as "Left"(en) => "Gauche"(fr) : the direction
I can't just put french translation for "Left,Gauche" because in other Doctype "Left" really mean "to leave"
I suggest to have a contextual translation options here

Explain the details for making this change. What existing problem does the pull request solve?

send dt and df in parse_option to allow __(xx,null,context) top be build correctly according the context

no-docs

[cogk]

Let's make sure that variable names make sense in the future 😄

df is often used for the docfield object, not just it's name. So this could be confusing

[FHenry]

@barredterra Don't you have the same issue with German translation ?

[barredterra]

Currently the code generating the translation files only allows for two context types:

1. arbitrary string literals used as parameter to the translation function (no variables allowed)
2. the DocType name (can be a variable)

So, if you change your code to only use the DocType as context, this should be good to go.

See also: #24903

[FHenry]

@barredterra This is not the only case where context is "Typed/field" named

frappe/frappe/public/js/frappe/utils/utils.js

Line 1114 in 2953c16

duration += total_duration.days + __("d", null, "Days (Field: Duration)");

Here there is type of the field and another information for the context

[barredterra]

Yes, but there it's a string literal, not a variable.

[cogk]

__("d", null, "Days (Field: Duration)");

This translation context with Field: is specific to get_formatted_duration and the Duration control. In the select it would be more compatible with the rest of the framework to use case 2. suggested by Raffael (= the DocType name only)

[FHenry]

ok, ok, I tried.

@barredterra, once again for me: RTFM , shame
I missed the bench get-untranslated and bench update-translations,
if that what you mean by "code generating the translation files"

But I will push a little more : The real "unique key" of translation is DocType (or context) + FieldName.
Imagine if in DocType Letter Head, there are two strings (label/output/select value/link....), one "Left" (as direction) and another another "Left" (as Exit), we were at the same point as today. In this case, you can always tell me that Frappe team will make the effort to use a synonymy in one of them, it will close the subject...., may be but may be not.
I will dig the path bench get-untranslated allow variable in context.

If you both think this PR have no chance to be merge, I will close it in favor of @cogk PR (#26425) (hoping it will be merge), but I still believe that all output have to be contextualize in a unique way.
The work you've done @barredterra on #24903 is amazing that's really reassuring to see how you push feature in Frappe Framework.