Translation for time zone conversion runner

[Natalie Clarius]

 Hi all,

While I agree that it would be very nice to have more flexibility, bells and whistles, I must reiterate that any sort of advanced natural language understanding as suggested in some of the previous mails is nowhere possible in the scope of what we're doing here. Organizations like Google have thousands of paid developers and specialized researchers working on their AI over years. It is not something a hobby developer can rig up on a weekend afternoon. Relevant XKCD https://xkcd.com/1425/ :)

I think Thomas' suggestion is a good idea: 

> use keywords like «@» or «->» in the 
runner grammar? Using such technical keywords would prevent people from 
thinking they can write in natural language.

Perhaps we don't need the "@", but ">" is already used in the unit conversion runner for the exact same thing. So my suggestion would be that we either amend or replace the translatable "in" keyword by "->" and ">", so that a user can type a query like "10:00 Paris > Tokyo". This way we avoid both untranslatable assumptions about English grammar and unmet expectations about what users can ask the runner. If noone objects, I will submit a merge request in the following days. Translators won't have to do anything else then. I hope this is a solution that turns out doable for all languages. Thanks for your work.

Natalie



    Am Sonntag, 12. Februar 2023 um 11:37:59 MEZ hat Karl Ove Hufthammer <karl at huftis.org> Folgendes geschrieben:  
 
 Natalie Clarius skreiv 12.02.2023 05:16:
> What I can offer is to make the syntax even simpler. In a previous 
> version, I had the input format as "<from-timezone> <time> 
> <to-timezone>", e.g. "Berlin 8:00 UTC" to convert 08:00 Berlin time to 
> UTC. It was suggested to change it to the "8:00 Berlin in UTC" style 
> because, on the one hand, it was similar to what we already have in 
> the unit conversion runner, and on the other hand, they (a native 
> English speaker) considered it more intuitive. But I see now that this 
> causes more problems than it solves, because it is pretending a 
> complexity of understanding that isn't there, and won't work for 
> languages that aren't English. So I am now leaning towards changing 
> the input format to "<from-timezone> <time> <to-timezone>", which 
> doesn't have any bells and whistles to cause wrong expectations and 
> inconsistency between languages.

My vote is *for* having the ‘bells and whistles’. The ‘natural’ syntax 
is what I would intuitively use and am familiar with from systems like 
Google and Wolfram Alpha, so that is what I would *try*. Having it makes 
the feature much more discoverable.

For Norwegian, we would like support for more than one translation 
(synonyms) of the ‘in’ keyword. We would use both the translation ‘i’, 
‘på’ and ‘som’. For names of cities and countries, ‘i’ sounds natural:

   15:00 i New York

For names of countries that are also islands, we would use ‘på’ (which 
means ‘on’):

   15:00 på Cuba

For technical names of time zones, ‘som’ (which means ‘as’) sounds more 
natural:

   15:00 som UTC

The words can be treated as synonyms, so it’s not a problem if the user 
types ‘15:00 i UTC’ or ‘15:00 som Cuba’ (even though the latter one 
*sounds* strange for a n native speaker).

Some users might also type the prefix ‘klokka’ (similar to the *suffix* 
‘o’clock’ in English):

   klokka 15:00 i New York

So it would be nice if this was supported, e.g., simply as a list of 
prefixes or suffixes that would be *ignored* when parsing the string.


-- 
Karl Ove Hufthammer

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