#time parser function can't read local language month names
OpenPublic

Description

Author: folengo

Description:
On the English Wikipedia, one may use {{#time: Y-F-d | {{{date}}} }}, with {{{date}}} being a string such as "15 may 1998".

The same programming cannot be used on the French or any other language Wikipedia, because a French date like "15 mai 1998" can't be read by the #time parser function and results in "Error: invalid time".

According to the help page on Mediawiki.org (1),

« The date/time object can be in any format accepted by PHP's strtotime() function. ».

So I guess that this "strtotime function", should be internationalized into strtotime/fr, strtotime/de, strtotime/es etc...

(1) http://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time:


Version: unspecified
Severity: enhancement

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz19412.
bzimport created this task.Via LegacyJun 26 2009, 2:24 PM
jayantanth added a comment.Via ConduitMar 20 2010, 9:09 AM

we are facing the same issue #time parser function in Bengali wikipedia(2) when we use {{#time: Y-F-d | {{{date}}} }}. The out put "Error: invalid time". Because of Bengali date like "15 মার্চ 2010" can't be read by the #time
parser function.

(1)http://bn.wikipedia.org/

bzimport added a comment.Via ConduitJun 17 2010, 10:47 AM

mahir78 wrote:

I also facing the same issue. I tried for http://ta.wikinews.org/

duplicatebug added a comment.Via ConduitAug 5 2010, 6:29 PM
  • Bug 24674 has been marked as a duplicate of this bug. ***
Platonides added a comment.Via ConduitMar 6 2011, 3:11 PM

strtotime() is a PHP function: http://www.php.net/strtotime
There's no hook inside php to change timelib_lookup_month.
ext/date/lib/parse_date.c

We would need to roll our own in order to support this.

bzimport added a comment.Via ConduitMar 6 2011, 3:26 PM

p.selitskas wrote:

Yes, as long as #time is processed by internal date-time PHP functions, the only way to implement this is to carry out backward convertion. I'm not actually sure it's MediaWiki which should do this. PHP modude would be great. It's quicker as well.

kaldari added a comment.Via ConduitMar 15 2011, 6:02 AM

Perhaps a PHP bug should be filed as well then. http://bugs.php.net/

Nikerabbit added a comment.Via ConduitMar 15 2011, 6:07 AM

Nah, PHP probably just got it from somewhere else. They actually do have http://fi.php.net/manual/en/function.strptime.php but that looks inadequate. I've been playing with the idea a bit: http://translatewiki.net/wiki/LocalTime

duplicatebug added a comment.Via ConduitMar 24 2011, 6:57 PM
  • Bug 28203 has been marked as a duplicate of this bug. ***
Siddhartha-Ghai added a comment.Via ConduitFeb 3 2012, 8:58 PM

Siddhartha.Ghai wrote:

Just a note, maybe someone could conjure up a wrapper for the current #time in mediawiki itself that would replace default month names by the localized month names. Such a wrapper (if possible) may not be an ideal solution, but if there's no ideal-ish solution in sight; I think even an untidy/inefficient mediawiki implementation would be much more efficient than template structures that might need to be created just because of this bug. For example: http://hi.wikipedia.org/wiki/%E0%A4%B8%E0%A4%BE%E0%A4%81%E0%A4%9A%E0%A4%BE:%E0%A4%A4%E0%A4%BF%E0%A4%A5%E0%A4%BF_%E0%A4%9C%E0%A4%BE%E0%A4%81%E0%A4%9A is a template I had to create just for verifying the monthname yyyy date format. And every other format will probably require more templates/subtemplates. So maybe this should be resolved before template behemoths to fix it spring up on wikis instead of the other way round (which is what usually happens AFAIK). :)

Platonides added a comment.Via ConduitFeb 3 2012, 9:26 PM

Why don't you pass {{CURRENTMONTHNAME}} and {{CURRENTYEAR}} as different parameters?

jayantanth added a comment.Via ConduitFeb 4 2012, 6:51 AM

(In reply to comment #10)

Why don't you pass {{CURRENTMONTHNAME}} and {{CURRENTYEAR}} as different
parameters?

How do we calculate
{{#time:Y F j|{{{1|{{CURRENTYEAR}}}}}-{{{2|{{CURRENTMONTH}}}}}-{{{3|{{CURRENTDAY}}}}}}}

and

{{#time:Y F j|{{{1|{{CURRENTYEAR}}}}}-{{{2|{{CURRENTMONTH}}}}}-{{{3|{{CURRENTDAY}}}}} -1 days}}

this type of calculation in all wiki's other than English wiki.

Template use in http://en.wikipedia.org/w/index.php?title=Portal:Current_events/Inclusion

Siddhartha-Ghai added a comment.Via ConduitFeb 4 2012, 6:04 PM

Siddhartha.Ghai wrote:

(In reply to comment #10)

Why don't you pass {{CURRENTMONTHNAME}} and {{CURRENTYEAR}} as different
parameters?

Well, firstly, I'd have to fix up http://hi.wikipedia.org/wiki/Template:Multiple_issues to accept two parameters (this isn't a big deal), then I'd have to fix up Twinkle to pass two parameters to the template,(big deal for me) and then I'd have to get users who input the template manually to use two parameters instead of one (really really big deal). Even after that, I'd still need a date check mechanism for the current transclusions, (or I'll have to manually fix them). And I find doing all that stuff much more difficult than creating a template like this.

And this particular format aside, using different parameters doesn't really solve the problem (as evident by Jayant's example above). I really think a solution for this should be found before more templates start springing up.

Platonides added a comment.Via ConduitFeb 5 2012, 8:04 PM

(In reply to comment #11)

(In reply to comment #10)
> Why don't you pass {{CURRENTMONTHNAME}} and {{CURRENTYEAR}} as different
> parameters?

How do we calculate this type of calculation in all wiki's other than English wiki.

I don't remember a wiki where different they do calculations with them, yet they don't use different parameters
http://commons.wikimedia.org/wiki/Template:Nsd
http://fr.wikipedia.org/wiki/Mod%C3%A8le:Source_inconnue_dat%C3%A9e
http://es.wikipedia.org/wiki/Plantilla:Sin_relevancia

If {{CURRENTMONTHNAME}} is on its own parameter a MONTH2NUMBER template is trivial and future proof.

bzimport added a comment.Via ConduitFeb 18 2012, 4:26 PM

Bisrin wrote:

Please solve this issue as soon as possible, and make all numbers and months in Assamese language. I have tried some parser functions in the field of Info boxes in As wiki. Please have a look. Assamese wiki in a begging state. So in this time it will be better to solve it. Otherwise it will cause a lots of problem later on.

(Bishnu Saikia)

SPQRobin added a comment.Via ConduitDec 19 2012, 8:02 PM

This doesn't seem like a tracking bug, so removing bug 2007 as depending on this one (and updating title and removing "tracking" keyword).

bzimport added a comment.Via ConduitMar 8 2013, 9:31 PM

dr.trigon wrote:

In my oppinion (vote +1 ;) this bug should really (!) be solved - best would be fast since it is open for quite a while now...

First it is VERY inconsisten since 5 tildes (~~~~~) returns e.g. on dewiki a date string that is not compatible with #timel! So either this bug is solved or 5 tildes should at least return something compatible (e.g. en locale, ISO format or something else...).

Second this is inefficient since because of the 5 tilde issue we would heave to use someting like {{subst:#time:Y-m-d}} which lanches parsing functions without any need for it.

So I think it would really be worth considering to solve this bug in near future.

Thanks a lot and Greetings
(DrTrigon)

bzimport added a comment.Via ConduitMar 8 2013, 11:48 PM

p.selitskas wrote:

By the way, can CLDR data be used to implement this?

jayantanth added a comment.Via ConduitJun 14 2013, 11:46 AM

Any progress for this bug??

bzimport added a comment.Via ConduitJun 14 2013, 11:53 AM

p.selitskas wrote:

(In reply to comment #18)

Any progress for this bug??

I wish there was any. Anyway, now with Lua enabled ([[mw:Scribunto]]) you can parse strings and match their pieces against month names and convert the original timestamp to a normalized (ISO format, for instance).

bzimport added a comment.Via ConduitAug 28 2013, 1:33 PM

p.selitskas wrote:

*** Bug 43714 has been marked as a duplicate of this bug. ***

Huji added a comment.Via ConduitAug 28 2013, 6:35 PM

I beg to disagree with marking Bug 43714 as a duplicate of this one. There are two issues at hand:

  1. When the month name is in a non-English language (such as "mai" in French, which is the same as "may" in English), the bug can be solved by finding a way that would replace month names with their English counterpart, then uses php's strtotime. This is what current bug is all about.
  1. When there is a calendar involved (as in Bug 43714, which talks about the Jalali calendar), then a simple conversion of month names to English is not enough. As explained on PHP's documentation, strtotime only accepts certain date formats -- which are described on http://www.php.net/manual/en/datetime.formats.date.php -- and it ONLY works with the Gregorian calendar. So converting "آذر" to "Azar" (a Jalali month name) won't help anything in this case.

The possible solution with Bug 43714 is to take the date string (which is normally in Persian or English), figure out the Jalali date, use existing MediaWiki code to convert it to Gregorian date, then pass that to the wrapper function (such as the function that handles #time), and take the output of that wrapper function, use existing MediaWiki code to convert it back to Jalali, then localized to the user's language of choice and return the localized string.

bzimport added a comment.Via ConduitAug 28 2013, 7:24 PM

p.selitskas wrote:

(In reply to comment #21)

I beg to disagree with marking Bug 43714 as a duplicate of this one. There
are
two issues at hand:

  1. When the month name is in a non-English language (such as "mai" in French, which is the same as "may" in English), the bug can be solved by finding a way that would replace month names with their English counterpart, then uses php's strtotime. This is what current bug is all about.
  2. When there is a calendar involved (as in Bug 43714, which talks about the Jalali calendar), then a simple conversion of month names to English is not enough. As explained on PHP's documentation, strtotime only accepts certain date formats -- which are described on http://www.php.net/manual/en/datetime.formats.date.php -- and it ONLY works with the Gregorian calendar. So converting "آذر" to "Azar" (a Jalali month name) won't help anything in this case.

    The possible solution with Bug 43714 is to take the date string (which is normally in Persian or English), figure out the Jalali date, use existing MediaWiki code to convert it to Gregorian date, then pass that to the wrapper function (such as the function that handles #time), and take the output of that wrapper function, use existing MediaWiki code to convert it back to Jalali, then localized to the user's language of choice and return the localized string.

I was watching bug 43714 from a quite more distant point. Currently, all datetime-related stuff is processed by PHP internals. On the other hand, we have CLDR (it stores all those intl'ed "+1 week") and MediaWiki calendar conversion functions, which have been used here... never, I guess.

Adding work-arounds into ParserFunctions would be dirty, and this code would demand not just refactoring, but rethinking and redesign. Moreover, ParserFunctions is not the right place for "low-level" language manipulations.

We can forward prerequisite datetime conversion into Language, as well as calendar detection, although if made straightforward, such piece of code would not be ... beautiful, assuming that, given a certain locale (wgLanguage), {{#time}} must accept every possible date format (in all terms: different month names, different calendars, time spans, etc.).

Otherwise, you can remove the duplicate sign and make the bug dependent on this one if it helps the community track the status of _their_ issue, of course!

kaldari added a comment.Via ConduitNov 2 2013, 6:09 PM

This isn't a trivial problem to fix, especially since, as Huji mentions, some month names are associated with different calendars (or even multiple calendars). Take "Nisan" for example. In the Hebrew calendar, Nisan is sometimes month 7 and sometimes month 8. However, Nisan is month 1 in the Assyrian calendar (and the Hebrew ecclesiastic calendar). We would need to add explicit flags for not only language, but also calendar, which would then necessitate considering all the different possible ways of writing dates and times in each language and calendar, as well as how to deal with the almost infinite number of ambiguous cases. Even the relatively "simple" case that we currently support, English-only Gregorian calendar, is fraught with bugs and inconsistencies. Just imagine multiplying that by 300 languages and then multiplying again by the 50 or so calendars currently in use around the world (some of which are quite difficult to convert to the Gregorian calendar). Not to mention that some languages support multiple number systems.

In the history of computer programming, no one has ever solved this problem, and honestly I doubt anyone ever will. Even a modest attempt would probably need its own open source project separate from MediaWiki.

My suggestion for a practical solution would be to distribute the problem and have each wiki write their own Lua module for translating their particular language and calendars into ISO 8601 compatible date-time formats. Each module could then be used to provide the input for #time.

Recommend WONTFIX.

bzimport added a comment.Via ConduitJan 3 2014, 5:36 PM

mgharish wrote:

We have the same problem in KN:WP.

In many of the calendar templates which we imported from EN:WP, there are expressions like this:

{{#ifexpr:{{#time:t|{{{year|2000}}}-{{{month|jan}}}}}>28|29}}

which promptly gets expanded to

{{#ifexpr:31>28|29}}

which promptly returns 29.

However, the same expression in KN:WP will result in this:

{{#ifexpr:{{#time:t|{{{year|2000}}}-{{{month|jan}}}}}>28|29}}

{{#ifexpr:೩೧>28|29}}

which will throw an error:
Expression error: Unrecognized punctuation character "�"

Is there any workaround/solution for this?

bzimport added a comment.Via ConduitJan 3 2014, 6:27 PM

p.selitskas wrote:

(In reply to comment #24)

We have the same problem in KN:WP.

In many of the calendar templates which we imported from EN:WP, there are
expressions like this:

{{#ifexpr:{{#time:t|{{{year|2000}}}-{{{month|jan}}}}}>28|29}}

which promptly gets expanded to

{{#ifexpr:31>28|29}}

which promptly returns 29.

However, the same expression in KN:WP will result in this:

{{#ifexpr:{{#time:t|{{{year|2000}}}-{{{month|jan}}}}}>28|29}}

{{#ifexpr:೩೧>28|29}}

which will throw an error:
Expression error: Unrecognized punctuation character "�"

Is there any workaround/solution for this?

Your issue is not directly related to this one, but I can see it. You need to convert the digits to arabic glyphs.

As long as {{#time}} supplies you with Kannada digits, you need to use {{format:KANNADA_INTEGER|R}} (note "R" argument). For example, you can use this to fix the issue:

{{#ifexpr:{{formatnum:{{#time:t|{{{year|2000}}}-{{{month|jan}}}}}|R}}>28|29}}

Try it and report back if it works.

He7d3r awarded a token.Via WebNov 24 2014, 12:55 PM
mxn added a subscriber: mxn.Via WebNov 24 2014, 8:55 PM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.