Source of translations of future dates
It looks like (correct me if I'm wrong) the translations of dates in the future tense come from some external source. See column End https://www.openstreetmap.org/user_blocks or in https://www.openstreetmap.org/user_blocks/17361 the text "almost 10 years" doesn't come from Translatewiki. There is no such string to translate. Where does it come from? And why do we have translations for past dates "x days/hours ago" but we don't have for future days "in x years/days"?
It will come from https://github.com/svenfuchs/rails-i18n but some of them have been copied into our locale files I think.
Hi, you cannot take a string produced by Rails (or anything) and then just prepend or append any random words to it in OSM strings. That is just invalid Internationalization (i18n) of the program. You must allow for translation of whole strings or sentences, you cannot randomly concatenate strings into a sentence. The added words may change the context of the whole sentence and cause some of the other concatenated parts to require different forms of the translated words. See the discussion at https://translatewiki.net/wiki/Translating_talk:OpenStreetMap#About_Osm:User_blocks.helper.short.time_in_future_title/en .
That's certainly the ideal yes, but sometimes practicality gets in the way - we're not going to have full date customisation for every translation that includes a date because that would be impractical so the dates are translated separately and substituted in to the larger string.
It will come from https://github.com/svenfuchs/rails-i18n but some of them have been copied into our locale files I think.
You might be thinking of https://github.com/openstreetmap/openstreetmap-website/issues/2255, where we brought in the "time ago" translations so that they could be handled properly.
So in short, for times in the future we use rails-i18n directly, but for times in the past, we use our own translations, to improve accuracy.
@aceman444 On the linked conversation on Translatewiki, you say that "Končí o takmer 10 rokmi" is incorrect Slovakian. Can you help us understand this more please? Is "takmer 10 rokmi" correct in any context? Is it specifically about the future that makes it incorrect? Or is it related to the sentence construction (i.e. coming after "Ends in" that makes it incorrect? For example, in English, we have
- A duration of time: "about 10 years"
- A time in the future: "in about 10 years"
- Describing something ending in the future: "Ends in about 10 years".
In all three situations, the "about 10 years" is unchanged.
If we have more information, we can consider whether it is the phrase itself that is incorrect, or the usage to represent the future, or the usage in the longer sentence.
Yes, in English all the 3 phrases contain the same "almost 10 years", but in Slovak they should be different. The phrase "takmer 10 rokmi" is correct when it talks about the past ('X time-length ago'). But when it is in the future (English 'in X time-length') it should be different ('takmer 10 rokov'). There are declinations of words in Slovak so the context is important and simply we need to have full strings in OSM that can be translated correctly into every language. I think you currently use 3 forms on the OSM website:
- <X time-length> ago (in the past)
- in <X time-length> (in the future)
- <X time-length> (when talking about duration)
for <X time-length> you currently use the same string (X days/hours/weeks/years) and that is the bug, as the form of it depends on the context.
You would need in OSM to have all the strings for translation: %{count} hours ago %{count} days ago (Osm:Datetime.distance in words ago.x days) %{count} weeks ago %{count} months ago %{count} years ago almost %{count} years ago over %{count} years ago in %{count} hours in %{count} days (OSM string missing!) in %{count} weeks in %{count} months in %{count} years %{count} hours %{count} days (Osm:User blocks.helper.block duration.days) %{count} weeks %{count} months %{count} years
Of course all of them using the {{PLURAL|||}} syntax. And these strings must not be concatenated with other strings
Google Translate translates these into Slovak as:
almost 1 year -> takmer 1 rok
almost 2 years -> Takmer 2 roky
almost 5 years -> Takmer 5 rokov
in almost 1 year -> takmer za 1 rok
in almost 2 years -> Za takmer 2 roky
in almost 5 years -> Za takmer 5 rokov
almost 1 year ago -> Takmer pred 1 rokom
almost 2 years ago -> takmer pred 2 rokmi
almost 5 years ago -> takmer pred 5 rokmi
Is it incorrect? If it's correct, it means that in Slovak there is no a different form for future.
Well, that is mostly correct, but it is a coincidence. Some other language may need all 3 forms. And the bug is that even if OSM has that "almost 5 years" string, it only uses it for duration and not for the future form of "in 5 years" string, so the result in OSM is wrong and not what the Translator produced. But I do not suggest to do this, as some other language may then come out wrong. Next time you add a string with some other preposition instead of "in" and there would need to be another form of the words as none of those presented above will be correct. So all the various prepositions (like 'in', 'ago', 'with', 'to') need their own separate strings to translate.
Actually the ideal situation would be to present whole sentences where the times are used, like "Created X days ago" (Osm:Api.notes.comment.opened at html) and some language may call you out to do this (as the 3 forms discussed here and then concatenated into other strings like "Osm:Api.notes.comment.opened at html" may not be enough). But then you would need to drop all the hours/day/months/years variants, as it would be insane to have all the combinations.
@aceman444 Thanks for the additional details. It would be helpful if you can share the exact slovakian translations of:
- A duration of time: "about 10 years"
- A time in the future: "in about 10 years"
- Describing something ending in the future: "Ends in about 10 years".
Unfortunately "in Slovak they should be different" and "Well, that is mostly correct" aren't quite specific enough to let me ensure we can fix the problem accurately!
As far as I can see so far, we have a few issues here.
- We can't translate every sentence that contains a duration, future time or past time separately. We have 13 different types of time, and each of those need a language-dependent number of translations (normally 2-4) and we use dates in many different places on the website. So some sort of consolidation and interpolation is necessary.
- rails has a few time helpers, and by default they use the same translation scope for every helper. (Some of the helpers are also slightly misleadingly named).
- We currently have two sources of time translations:
- rails-i18n, which we use for durations and future times
- our own distance_in_words_ago which we use for past times
- I think the problem might be that some translations in rails-i18n are correct for past times, and therefore not durations or future times (e.g. slovakian, see sk) but others are correct for durations/future times (e.g. de), see also #2255.
So to resolve this I think we need to do the following:
- Agree to stop using rails-i18n for time durations. Their translations are not grammatically consistent between languages as to whether they represent durations or past times.
- We already have our own translations for
distance_in_words_ago. But do we need separate sets of translations fordistance_in_words_durationanddistance_in_words_in_future? Or are they the same in each language? - Do we need separate translations for
distance_in_words_in_futureanddistance_in_words_in_future_in_a_sentence?
That is exactly what I propose in comment https://github.com/openstreetmap/openstreetmap-website/issues/5769#issuecomment-2715697075 . The 3 different contexts. It is true that in Slovak distance_in_words_duration and distance_in_words_in_future have the same form. But that may not be true for all languages.
Thanks for the additional details. It would be helpful if you can share the exact slovakian translations of:
- A duration of time: "about 10 years"
This would be "približne 10 rokov".
- A time in the future: "in about 10 years"
This would be "o približne 10 rokov".
- Describing something ending in the future: "Ends in about 10 years".
This would be "Končí o približne 10 rokov". In Slovak you can in this case prepend "Ends" before the "in about 10 years" . But it again may not work in other languages. But if you offered the full string for translation (which would be the ideal case) you have the problem as described below.
As far as I can see so far, we have a few issues here.
- We can't translate every sentence that contains a duration, future time or past time separately. We have 13 different types of time, and each of those need a language-dependent number of translations (normally 2-4) and we use dates in many different places on the website. So some sort of consolidation and interpolation is necessary.
Correct. You would have to drop those 13 types of time. If there was only one, then you could provide every sentence complete for translation. Most of them are only used for past times (e.g. creation times of something). Only the block times are in the future.
- rails has a few time helpers, and by default they use the same translation scope for every helper. (Some of the helpers are also slightly misleadingly named).
- We currently have two sources of time translations:
- rails-i18n, which we use for durations and future times
- our own distance_in_words_ago which we use for past times
- I think the problem might be that some translations in rails-i18n are correct for past times, and therefore not durations or future times (e.g. slovakian, see sk) but others are correct for durations/future times (e.g. de), see also Better translations for time_ago_in_words #2255.
Correct, Rails only has one form of the words and does not distinguish which (future or past) context you need. So it has one and serves it to OSM and it is then used wrongly into concatenated strings. It fails for Slovak, but may be correct in other languages. If you say different languages actually have different contexts (past/future) written in that 1 Rails form, then it is indeed a mess and that may be why not many people complained yet.
But that may not be true for all languages.
But if no one has reported so far that they are needed, I think we should not change anything now.
Because if we change, and no language needs such a change, it will add work to the translators.
Maybe other translators are not aware and do not check how the strings are really used on the webpage. Some of the strings have very good context descriptions of their usage directly at the weblate interface (thanks!). But some have none. I have found the same problem with the future time intervals ('in X months') exists also in the Czech language (cs).
Are rails-i18n and homegrown translation strings the only options for formatting dates? On the client side, JavaScript has a robust API for formatting relative dates according to a given locale. Probably every browser implementation of this API is powered by CLDR, which is the industry standard for this sort of thing. If we can find a Rails library that pulls data from CLDR, then we don’t need to burden translators with every permutation that their language doesn’t need. Or we could leave it as an absolute timestamp and rely on JavaScript to relativize it on the fly.
Well rails-i18n does draw on some CLDR concepts but I don't believe that CLDR has translations for all the different relative dates that we're talking about here does it?
CLDR has string formats for future/past relative years/months/etc. However, it doesn’t have any provisions for “about”. As far as I know, “about” timestamps are relatively rare these days, since most software would write out the specific date past a certain point. There are also options for formatting durations more generally, but not as part of a preposition, and also without any “about”.
This happens to be something I’m looking into for OpenHistoricalMap’s fork, since we want to indicate something about actual approximations in the data (such as “circa 1902”): OpenHistoricalMap/issues#981. Unfortunately, there aren’t any great well-translated libraries for the particular data format we’re using, but the use case is a little different than OSM’s anyways.
I have a suspicion German language also has this problem with future time intervals. The OSM blocks page writes "in 10 Jahre", instead of "in 10 Jahren", also "in etwa ein Jahr" instead of "in etwa einem Jahr". Intervals in past seem OK, "vor etwa einer Stunde", "vor einem Tag", "vor 3 Tagen". German has declensions too depending on context (grammatical case). But please call a German speaker onto this.
The future dates are also used in the string 'Osm:Notes.show.disappear date html' (This resolved note will disappear from the map in %{disappear_in}.), so this may be more visible to the users than in the user blocks page.
Or we could leave it as an absolute timestamp and rely on JavaScript to relativize it on the fly.
Another advantage of client-side relative dates is that we can make them update dynamically as you’re viewing the page. For example, on this page (and also on the wiki if you have the Comments in Local Time gadget installed), the time on a recent comment updates live. However, a timestamp younger than a minute or older than than a week remains as an absolute date, so that the user doesn’t have to do the math in their head.
Fw: message by Ceirios [Cymru] (soiriec, formerly rose#3000); cc: @ceirios-osm https://discord.com/channels/413070382636072960/429092644438802432/1399504959929581638
One thing I have noticed is that it might be better to use Unicode CLDR for things like times and dates. I noticed some things don’t handle mutations properly [...in Welsh (
cy)] "2" is supposed to cause a soft mutation here
- day / days: diwrnod / ddiwrnod
- month / months: mis / fis
- year / years: blynedd / flynedd)
same thing happens with months and years they are translated properly over on Translatewiki i think, i checked multiple times
See also #375, #631, #4067, #5878, #6266
Or we could leave it as an absolute timestamp and rely on JavaScript to relativize it on the fly.
I split this idea out as #6534. Sorry for opening yet another issue about timestamps, but my comments here seemed a bit off-topic for an issue primarily about translations.