Last modified: 2014-11-17 10:35:07 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:
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/
I also facing the same issue. I tried for http://ta.wikinews.org/
*** Bug 24674 has been marked as a duplicate of this bug. ***
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.
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.
Perhaps a PHP bug should be filed as well then. http://bugs.php.net/
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
*** Bug 28203 has been marked as a duplicate of this bug. ***
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). :)
Why don't you pass {{CURRENTMONTHNAME}} and {{CURRENTYEAR}} as different parameters?
(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
(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.
(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.
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)
This doesn't seem like a tracking bug, so removing bug 2007 as depending on this one (and updating title and removing "tracking" keyword).
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)
By the way, can CLDR data be used to implement this?
Any progress for this bug??
(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).
*** Bug 43714 has been marked as a duplicate of this bug. ***
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.
(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!
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.
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?
(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.
