Last modified: 2014-11-17 10:35:07 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 19412 - #time parser function can't read local language month names
#time parser function can't read local language month names
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
ParserFunctions (Other open bugs)
unspecified
All All
: Low enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: i18n
: 24674 28203 43714 (view as bug list)
Depends on:
Blocks: 34174 34193 40760
  Show dependency treegraph
 
Reported: 2009-06-26 14:24 UTC by folengo
Modified: 2014-11-17 10:35 UTC (History)
22 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description folengo 2009-06-26 14:24:00 UTC
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:
Comment 1 Jayanta Nath 2010-03-20 09:09:42 UTC
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/
Comment 2 Mohamed Mahir 2010-06-17 10:47:27 UTC
I also facing the same issue. I tried for http://ta.wikinews.org/
Comment 3 db [inactive,noenotif] 2010-08-05 18:29:52 UTC
*** Bug 24674 has been marked as a duplicate of this bug. ***
Comment 4 Platonides 2011-03-06 15:11:22 UTC
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.
Comment 5 Pavel Selitskas [wizardist] 2011-03-06 15:26:36 UTC
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.
Comment 6 Ryan Kaldari 2011-03-15 06:02:15 UTC
Perhaps a PHP bug should be filed as well then. http://bugs.php.net/
Comment 7 Niklas Laxström 2011-03-15 06:07:48 UTC
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
Comment 8 db [inactive,noenotif] 2011-03-24 18:57:23 UTC
*** Bug 28203 has been marked as a duplicate of this bug. ***
Comment 9 Siddhartha Ghai 2012-02-03 20:58:11 UTC
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). :)
Comment 10 Platonides 2012-02-03 21:26:58 UTC
Why don't you pass {{CURRENTMONTHNAME}} and {{CURRENTYEAR}} as different parameters?
Comment 11 Jayanta Nath 2012-02-04 06:51:06 UTC
(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
Comment 12 Siddhartha Ghai 2012-02-04 18:04:48 UTC
(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.
Comment 13 Platonides 2012-02-05 20:04:31 UTC
(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.
Comment 14 Bishnu Saikia 2012-02-18 16:26:13 UTC
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)
Comment 15 Robin Pepermans (SPQRobin) 2012-12-19 20:02:31 UTC
This doesn't seem like a tracking bug, so removing bug 2007 as depending on this one (and updating title and removing "tracking" keyword).
Comment 16 DrTrigon 2013-03-08 21:31:51 UTC
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)
Comment 17 Pavel Selitskas [wizardist] 2013-03-08 23:48:42 UTC
By the way, can CLDR data be used to implement this?
Comment 18 Jayanta Nath 2013-06-14 11:46:21 UTC
Any progress for this bug??
Comment 19 Pavel Selitskas [wizardist] 2013-06-14 11:53:12 UTC
(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).
Comment 20 Pavel Selitskas [wizardist] 2013-08-28 13:33:59 UTC
*** Bug 43714 has been marked as a duplicate of this bug. ***
Comment 21 Huji 2013-08-28 18:35:12 UTC
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.
Comment 22 Pavel Selitskas [wizardist] 2013-08-28 19:24:45 UTC
(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!
Comment 23 Ryan Kaldari 2013-11-02 18:09:59 UTC
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.
Comment 24 M G Harish 2014-01-03 17:36:58 UTC
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?
Comment 25 Pavel Selitskas [wizardist] 2014-01-03 18:27:40 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links