[Wikidata-bugs] [Maniphest] T325988: MonthNameUnlocalizer may unlocalize dates in an undesired way

matej_suchanek added a project: Patch-For-Review. matej_suchanek assigned this task to Lucas_Werkmeister_WMDE. TASK DETAIL https://phabricator.wikimedia.org/T325988 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE, matej_suchanek

[Wikidata-bugs] [Maniphest] T325988: MonthNameUnlocalizer may unlocalize dates in an undesired way

Lucas_Werkmeister_WMDE added a comment. Proposed fix: https://github.com/wmde/Time/pull/167 TASK DETAIL https://phabricator.wikimedia.org/T325988 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE Cc: Michael, Lucas_Werkmeister

[Wikidata-bugs] [Maniphest] T325988: MonthNameUnlocalizer may unlocalize dates in an undesired way

matej_suchanek added a comment. I believe it doesn't. This problem occurs in `PhpDateTimeParser`, which is used after the other two fixed parsers. So as long as they "catch" all these dates (and I hope they now do), `PhpDateTimeParser` simply won't be used and this bug should not happen. TA

[Wikidata-bugs] [Maniphest] T325988: MonthNameUnlocalizer may unlocalize dates in an undesired way

Lucas_Werkmeister_WMDE added a comment. We should probably fix this in either case, but do you know if this still results in any broken parses when your change to construct parsers with a copy of ParserOptions is appl

[Wikidata-bugs] [Maniphest] T325988: MonthNameUnlocalizer may unlocalize dates in an undesired way

matej_suchanek added a comment. "all-numeric" should already be handled in both TimeParserFactory and MonthNameUnlocalizer

[Wikidata-bugs] [Maniphest] T325988: MonthNameUnlocalizer may unlocalize dates in an undesired way

Lucas_Werkmeister_WMDE added a comment. Yeah, that’s true, I lost sight of that while pondering the potential greater horrors of `5. 4. 1891` not even parsing the same (broken) way all the time. The `MonthNameUnlocalizer` should probably skip any replacements that… only contain numbers a

[Wikidata-bugs] [Maniphest] T325988: MonthNameUnlocalizer may unlocalize dates in an undesired way

matej_suchanek added a comment. > But in the case of `5.` vs. `4.`, the length is the same; since PHP 8.0, uksort retains the original order in that case, but in production (PHP 7.4, until T319432

[Wikidata-bugs] [Maniphest] T325988: MonthNameUnlocalizer may unlocalize dates in an undesired way

Lucas_Werkmeister_WMDE added a comment. I think this only affects Czech and Korean, though, or at least I haven’t found purely numeric abbreviated month messages (`jan` etc. as the message key) in other languages. TASK DETAIL https://phabricator.wikimedia.org/T325988 EMAIL PREFERENCES h

[Wikidata-bugs] [Maniphest] T325988: MonthNameUnlocalizer may unlocalize dates in an undesired way

Lucas_Werkmeister_WMDE added a comment. > The abbreviated month is always a number followed by a dot. Therefore, if the input is in the DD. MM. format, the day may be replaced instead of the month (since during replacement string is scanned left-to-right). > For example, `5. 4. 1891` (

[Wikidata-bugs] [Maniphest] T325988: MonthNameUnlocalizer may unlocalize dates in an undesired way

matej_suchanek created this task. matej_suchanek added a project: Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION MonthNameUnlocalizer is used by PhpDateTimeParser