Translation for time zone conversion runner

[Natalie Clarius]

In addition, the runner will display information on the time difference between the two time zones. For example, "10:00 CET in China" would show "China Standard Time: 17:00 (7 hours later)".  This was (back then in a slightly different from perhaps) already introduced as a change on its own a couple weeks ago and the time zone conversion feature.

The time difference (e.g. "7 hours") is formatted according to the user's locale, using the formatSpelloutDuration function from the KFormat library, so localization of this part would already be taken care of.

Translators should provide their language's translation for "later"/"earlier"/"no difference". The time difference string, formatted as described above, is passed as an argument, so it is possible for you to specify it in the right word order for your language, in case your language expresses it as something like "later by 7 hours". Or did I still miss a case here?

Same for the date difference string that will be attached in the case a time zone difference passes midnight, e.g. "21:00 CET in China" would show "... 04:00 + 1 day ...". The "04:00 and "1 day" arguments again already come in localized form, and all that this translation string is needed for is how to combine them, just in case there is some region where "+ 1 day 04:00" or something would be the more natural way of writing it. Maybe that part was confusing.

What is currently fixed is the order "<zone name>: <time incl. possible date difference> (<time difference>". Do we need to liberalize this output format and wrap this into something localizable as well?


    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/b18d947e/attachment.htm>