Translation for time zone conversion runner

[Shinjo Park]

Hello,

I looked into the MR but I couldn't find anything related to the timezone. 
Could you please more elaborate on it?

You should not assume that every language has short 3-letter code for pointing 
out timezones. We (in Korean) don't have abbreviation for timezone so we have 
to write the timezone name in full. Timezone name in English abbreviation 
would be accepted though.

An example of the literal translation of <time> <from timezone> <in> <to 
timezone> format in Korean would be like this:

<10:00> <대한민국 표준시>를 <중부 유럽 표준시>로 (10:00 KST in CET)

> The order "<time> <from timezone> <in> <to timezone>" is fixed, and was
> chosen in analogy to how the unit conversion runner works (e.g. "2 liters
> in milliliters"). Is there any language where this syntax for time zone
> conversion would not be natural at all?

For Korean, both <from timezone> <time> and <time> <from timezone> will be 
expected. Also no spacing before <in>'s equivalent is expected. I can imagine 
at least three variants for 10:30 KST in CET:

<한국 표준시> <10:30>을 <중부유럽 표준시>로: <from timezone> <time><-obj> <to timezone><-
adj>
<10:30> <한국 표준시>를 <중부유럽 표준시>로: <time> <from timezone><-obj> <to timezone><-
adj>
<한국> 시간 <10:30>을 <중부유럽 표준시>로: <from city/country> <the word time> <time><-obj> 
<to timezone><-adj>
* The <-obj> and <-adj> part can have spelling variants which I can specify 
every form in the msgstr.

Moreover, there are also spelling and spacing variants for the timezone's 
name. "대한민국 표준시" could be written in "한국 표준시", "중부유럽 표준시" could be written in 
"중부 유럽 표준시" or even in "중앙 유럽 표준시". Users may enter either variant of full 
name of the timezone, but I don't think handling all variants will be 
feasible.

Best,
Shinjo

2023년 2월 10일 금요일 오전 12시 8분 57초 CET에 Natalie Clarius 님이 쓴 글:
> > Please explain how the input format works in words non-coders can
> > understand :)
> Oh, of course, sorry :) I thought the description in the linked MR would had
> made it clear enough. Currently, the query syntax for time zone conversion
> is:
> 
> <time> <from timezone> <in> <to timezone>
> 
> For instance, a user can type "10:00 CET in China" to convert 10:00 CET to
> China time and get 17:00 as a result.
> 
> <time> time is a specification of a time (eg "10:00") or date and time (eg
> "09.02.2023 10:00"). The code checks whether the user input matches a valid
> time specification according to the system locale's short time format, so
> no additional intervention is required by translators here.
> 
> <from timezone> and <to timezone> is the name (or a part of the name) of a
> time zone. These time zone names are matched in their localized form as
> provided by the Qt library, eg if the language is set to German, it would
> recognize "MEZ" as a time zone name for CET, so again, no manual
> translation is required for this part.
> 
> <in> is a natural language word that is suitable to specify a time in a time
> zone and/or to convert a time to a time zone, eg "current time *in* China"
> or "18:00 UTC *to* CET". This part is to be translated. In English, it is
> any of "to", "in", "as", "at". Translators can provide several suitable
> such words, and the code will check that any of them matches the user input
> at that position. If your language uses the same word for both usage
> contexts, just provide that one word; if it uses different words for the
> two usages or several for the same, just provide all of them in the same
> string, separated by "|" as said in the translation comment. Eg a suitable
> translation string for German for the "in"-words would be "in|nach|zu"
> ("in" can be used in the context for "current time in China", and all of
> "in", "nach" and "zu" can be used for "10:00 CET to China time"). Does this
> make it clearer?
> 
> The user can leave one of the two time zone slots out, and in this case, the
> converter will use their local time zone. For example, if the user's time
> zone is CET, "10:00 in China" would mean "convert 10:00 CET to China time",
> and "10:00 China" would mean "convert 10:00 China time to CET". In the case
> where the second time zone is left out, the "in" keyword can be left out
> too (as in the last example).
> 
> The order "<time> <from timezone> <in> <to timezone>" is fixed, and was
> chosen in analogy to how the unit conversion runner works (e.g. "2 liters
> in milliliters"). Is there any language where this syntax for time zone
> conversion would not be natural at all? Am Donnerstag, 9. Februar 2023 um
> 23:09:39 MEZ hat Albert Astals Cid <aacid at kde.org> Folgendes geschrieben:
> 
>  El dijous, 9 de febrer de 2023, a les 18:40:34 (CET), Natalie Clarius va
> 
> escriure:
> > Dear translators,
> > I authored the recently added time zone conversion feature for the
> > date-time runner. It was brought to my attention that the way the input
> > is parsed poses some problems for translation into various languages. I
> > actually intended to make the syntax not too natural-language-y, and we
> > decided to go with a format similar to what we already have in the unit
> > conversion runner. The discussion can be found here:
> > https://invent.kde.org/plasma/kwin/-/merge_requests/2587 But it appears
> > that I did not succeed in making it independent enough of peculiarities of
> > English syntax after all.
> > 
> > Could you point out which assumptions about the input format are
> > especially
> > problematic for translation, and how this could possibly be handled in a
> > better way?
> 
> Are you expecting all the translators to understand C++ code?
> 
> Please explain how the input format works in words non-coders can understand
> :)
> 
> Best Regards,
>   Albert
> 
> > Cheers,Natalie