Translation for time zone conversion runner

[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




  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-i18n-doc/attachments/20230209/50d3f95a/attachment-0001.htm>