Closed waldyrious closed 5 years ago
It’s capitalized in wiki_functions.inc.php, line 167 to make the YYYY, MM, DD placeholders case-insensitive. Maybe it should be changed to case-insensitive regex matches so that upper casing is not needed.
Thanks for reporting the problem and for finding the reason. I wasn't aware of this. @tacsipacsi Would you might providing a merge request of your approach? My regexp capabilities are very limited ;)
As an alternative one could use str_ireplace at line 179, I think.
Wouldn't it suffice to simply remove strtoupper
? That means the placeholders must be provided with the correct capitalization (e.g. "DD" instead of "dd"), but that's already the case in many date formatting syntaxes.
Besides, as far as I can tell, none of the current translations use those placeholders in lowercase anyway:
❯ rg 'date_format.+dd' wikiblame_inc | wc -l
0
❯ rg 'date_format.+mm' wikiblame_inc | wc -l
0
❯ rg 'date_format.+yyyy' wikiblame_inc | wc -l
0
❯ rg 'date_format.+DD' wikiblame_inc | wc -l
112
❯ rg 'date_format.+MM' wikiblame_inc | wc -l
117
❯ rg 'date_format.+YYYY' wikiblame_inc | wc -l
106
The discrepancy in the counts above is due to translations which mistakenly localized the placeholders, btw:
All of these should be fixed to use the literal tokens "DD", "MM" and "YYYY". But that's a different issue than this.
@siebrand : Can I simply delete the wrong translations in git or how do I get rid of them to have them retranslated?
I recommend to ping @translatewiki in the future to reach the whole team.
Deletion in the repo won't suffice. This would be a good case for a custom validator that prevents wrong translations. Then we can mark them as outdated or consider deleting, when we can be sure they won't be reintroduced.
Will try to remember and do that next time.
Where would such a custom validator be placed? How would it look like?
I'm am attempting to implement it. We have a new validator framework and this seems a good case for me to try it out myself.
Greetings,
I work with Niklas on the @translatewiki team. The patch mentioned by Niklas has been merged and deployed on Translatewiki.net.
Following validators / insertables have been added,
MM DD, YYYY
- The exact strings - YYYY
, MM
, DD
must be present in the translation.__NEEDLE__
& __REVISIONLINK__
must be present in the translation as is, without being translated.If the user does not put any of these, they'll be receiving an error and cannot save their translation.
Thanks. This looks pretty cool and intuitive. What do I need to do now to clean the translations mentioned at https://github.com/FlominatorTM/wikiblame/issues/24#issuecomment-513503896 ?
@FlominatorTM - I'll get back to you on that. We've some limitation with this file format, I'll have to check a bit and see what will be the best approach.
@Abijeet Any news? If not, when may I ask again?
@FlominatorTM - Sorry about the delay. I'll try to get back to you by Wednesday this week.
@FlominatorTM - You can go ahead and delete the translations that are not appropriate. Once done, please give me a link to the commit so I can do the same on Translatewiki.net.
I assume that fallback to English is configured in the source code if the translation does not exist?
Done that and yes, fallback in included.
I've removed the translations on Translatewiki.net. We ran an export today (45c74728dc9dbaeb0670c35c6a21a94fd597b082), and everything looks good
Seems to be fixed, right, @waldyrious ?
Yep, looks good now!
It looks like the date separators are getting capitalized. For example, in Portuguese the separator is
de
(as seen here), but in the interface they show up asDE
: