Translation for time zone conversion runner

[Emir SARI]

Hello,

For some reason I am not getting the replies from the original author, but anyway. I’ve seen the author's message from Shinjo’s reply.

As a disclaimer, I do not think handling natural language through translatable strings is a good idea, instead it should be handled via quirks in code for every supported language. It is simply not covering all cases, and English being one of the simplest languages out there, it does not help either.

> <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.

Why the variables are in <> brackets, is there a technical reason for this? My translator side has gotten used to seeing input placeholders in <> brackets, and now I realise that there may be relevant mistakes already because of this present. And since these are not reorderable, it’s problematic for my language. Hopefully I won’t need to dive into code every time I see these again.

In Turkish, due to the Subject-Object-Verb word order, nearly all of the standart English structures need to be flipped. So, "10:00 CET in China” becomes “Çin’de 10:00 MAS” (China-in 10:00 CET, yes it’s agglutinative, so that “in” becomes an issue already. I can think of something like “10:00 MAS için Çin saati” (China time for 10:00 CET), but I am really not sure if this sounds okay, and really forced. Also I’d need separate variants for date and time. It should really be re-orderable.

> "18:00 UTC *to* CET”

I’d just go with something like "18:00 UTC, CET" or "18:00 UTC CET” for the lazy. Not that it’s correct, but omission of a certain textual location makes it easier to forego. This works very nicely for European languages I see, but not necessarily for others.

> 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?

In unit conversion it works in Turkish, because luckily "2 kg in mg” is informally used as “2 kg kaç mg” (2 kg how much mg), but not for time zone conversions which apparently requires a more delicate and formal language syntax.

As another example; in Japanese, it’s also possible to use the same unit conversion syntax as in Turkish (2キログラムは何ミリグラム - 2 kilogram is what miligram), but not for time conversion (中国では 10:00 CET - China-in 10:00 CET). Japanese also uses the same word order as in Turkish (my Japanese is nowhere near proficient though).

Even without any proper language use, word order and whatnot; the system should be smart enough to make assumptions independently of the language settings, and put out soma results without being bound to translatable strings. Otherwise you get frustrated people that gets the features advertised to them but still can’t print results due to some translator error or too literal code.

To improve this in general, it would be nice to make everything re-orderable and spread out English variants as much as possible, and having the each target translations for these variants support more than one outputs separable with ‘;’ where it makes sense. Also avoid string concatenation at all costs!!!

If something is not clear, let me know. It’s very late over here, I’m not sure all my words made sense.

Best regards,
Emir (𐰽𐰺𐰍)

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