Translation for time zone conversion runner

[Emir SARI]

Hello Thomas, Natalie;

> Basically, you are attempting to find the proper grammar to say «convert the 
> time <T> from timezone <A> to timezone <B>».
> From the emails that have been exchanged so far, I understand there are 
> different – and specific – ways to write this in natural languages. Thus it 
> seems difficult to define one universal runner grammar that could conveniently 
> fit in all languages.
> 
> Here is my idea: would it be possible to use keywords like «@» or «->» in the 
> runner grammar? Using such technical keywords would prevent people from 
> thinking they can write in natural language.
> 
> For example, one may write «10:00 @Paris -> @Tokyo», or something like that.

While this is a good idea, it’s not logical to limit this to a one set of keyword, especially when we already have a basic foundation. Details below.

>> 
>> If, on the other hand, you say that both in Korean and in Turkish, a syntax
>> like "<time> <from timezone> in <to timezone>" (where the time zone, the
>> time zone names as well as a word for "in" are localized) is at least
>> somewhat feasible, at any rate after the fact that we have (likewise
>> translated) user help explaining how to use it, then I would say there is
>> not much of a problem, and you are good to go by simply translating the
>> "in" keyword and any strings that are used in the output formatting.

I believe I was not able to convey my message last time clearly in my previous message. Indo-European prepositional phrases do not work well at all with Turkic languages (and Japanese has a similar problem from my understanding, since it is agglutinative as well). If I remember correctly, Chinese also uses the 里 suffix to cover the “in” preposition if I remember correctly (another possible repositioning need).

From my point of view, making every keyword flexible and movable around, and accepting more than one input for every phrase solves the issue for many languages.

Another example; in definition runner, I’ve flipped the define keyword in order to accommodate Turkish. For instance, instead of “define x”, I’ve used “x tanımla”, but it still does not sound natural, because we tend to describe the object we want explained, or use genitive case suffixes with or without and apostrophe, otherwise it sounds very, very robotic. Like, “define x word”, but we overlook here that the “word” word might have synonyms, so that a user might’ve used “x sözcüğünü tanımla, x kelimesini tanımla, x sözünü tanımla”; or can prefer “define x item” -> “x ögesini tanımla, x öğesini tanımla, x nesnesini tanımla”; or “what is x” -> “x ne, x nedir”… and it goes on. I am not even getting into the subject of genitive case suffix vowels changing accordingly with the vowel harmony, I’ll simply omit that structure (x’i tanımla) in order to reduce complexity. We can just cover a lot of corner cases like these with multiple target strings. As you can see a perfect single keyword like “define” in English can be met with a lot of variants that all can be expected from a native speaker of another language.

And if the rest of the KRunner team is listening, if not please convey, please document all the uses in the docbook, so that we can assist people learning all the keywords, and simply present it as a reference source (and add our own quirks). I’d love to advertise it to my local community.

On the other hand, I am not sure if people will complain if we just use @ or ->, or just use <source> <target> structure WITHOUT ANY English specific things, what the hell, PERFECTLY OKAY; but if feasible, and won’t be a burden much, improvements such as explained above will improve the general experience by a huge margin in the Plasma environment. This is just my feedback about the general subject. Also I agree that parsing natural language using complex NLP algorithms is outside the current scope of KRunner. Gotta be thankful for what we have already :).

PS. I am still not getting Natalie’s e-mails.

Best regards,
Emir (𐰽𐰺𐰍)

** E-mail needs to stay simple
** Use plain text e-mail