I 100% see the point of avoiding to "waste translators' time", but I also see that completely removing tests is a big choice for upstream: being able to have people running unit tests and see the results in their language was a feature, so we also "waste a feature".

Premising, that Translators are heroes, and we should protect their time, let's also evaluate these:

To Translatewiki Heroes:

1. Would you be happy to try to move these strings into a dedicated translate package, e.g. called "tests", containing all tests, so, that you can easily ignore it forever? or, add Sicilian there for your unit tests if you want?

2. or, would you be happy to do the very same above thing, disabling the "tests" for the whole Translatewiki website, so that even Sicilian translators cannot - in any way - waste their time to complete this feature?
   • In case, is this doable from the Translatewiki side? so that we still have these strings include, and you just ignore these? Thanks for this extra clarification.

(Let's discuss the "AM" and "PM" issue in parallel, in another Task, since that is still another interesting thing to be fixed regardless of our action here, I think)

I think the costs of the extra translations are low, but the cost of "the tests are not being translated for developers" are even lower.

The chances of a someone understanding the development docs (English only) and the code (English and PHP) enough to contribute code, but be bothered by the tests error messages are quite low, IMO.

In T15815#17250, @valerio.bozzolan wrote:

being able to have people running unit tests and see the results in their language was a feature

I did not think of that but I can say that I do dislike this feature after experiencing 20 years of bad luck entering some badly (nearly incomprehensibly) localized CLI output into a web search engine to often get zero results (as a user, how can I easily switch (back) to English output, to copy that into a search engine instead?). ;)

Thanks. Completely agree.

I also don't think Phabricator ever documented how to change language in command line Arcanist. If ever possible, btw 🤔

In T15815#17273, @valerio.bozzolan wrote:

Thanks. Completely agree.

I also don't think Phabricator ever documented how to change language in command line Arcanist. If ever possible, btw 🤔

It should document it/support it if it isn't documented. I was wondering the same myself. But that's out of scope of this ticket.

In T15815#17273, @valerio.bozzolan wrote:

I also don't think Phabricator ever documented how to change language in command line Arcanist. If ever possible, btw 🤔

Should somebody file a ticket for that?

Should somebody file a ticket for that?

I'd prefer not to introduce and maintain such a feature. :)

https://we.phorge.it/source/arcanist/browse/master/src//internationalization/__tests__/PhutilPhtTestCase.php$34

// The only purpose of this function is to provide a static list of
// translations which can come from PhutilTranslator::translateDate() to
// allow translation extractor getting them.

I seem to have a bad habit of doing things and realizing they were stupid or I had missed something weeks to months later.

... but it turns out by concidence most of the date elements that are worth translating are already translatable from other references in the code:

Abbreviated weekday names ("D"):

https://we.phorge.it/source/phorge/browse/master/src//view/phui/calendar/PHUICalendarMonthView.php$365

Full weekday names ("l"):

https://we.phorge.it/source/phorge/browse/master/src//view/phui/calendar/PHUICalendarMonthView.php$365

English Day Ordinals ("S") are not translatable - I don't think Phorge uses ordinal days anyway but if something does hopefully the date format string itself is translatable so that can be translated out.

Full month names ("F"):

https://we.phorge.it/source/phorge/browse/master/src//view/form/control/AphrontFormDateControl.php$272

Abbreviated month names ("M") seem not to be anywhere, which is a problem but it's better to handle it downstream in the translation library (adding those strings manually) itself than hackaround it like this.

"AM" and "PM" can't be translated until T15811 is resolved, in either case.

Once a fix for T15811 is released and deployed by Wikimedia I will probably add the date strings that aren't also elsewhere via a downstream patch.