Page MenuHomePhorge

Make i18n string extraction ignore strings in test cases
Closed, ResolvedPublic

Description

A test case string translation of "AM" and "PM" (as part of a Time) triggered a downstream exception in https://phabricator.wikimedia.org/T363215, thus upstreaming this from https://phabricator.wikimedia.org/T363364. See also D25618 for the specific issue.

private function loadLibraryFiles() in https://we.phorge.it/source/phorge/browse/master/src/infrastructure/internationalization/management/PhabricatorInternationalizationManagementExtractWorkflow.php$279 was added in https://we.phorge.it/rPccc7c1b42436dcdbc19d1239427f31cc6a02c7ba.

It makes sense not to make the upstream core code extract strings in test files for localization in order not to waste translators' time.

Event Timeline

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?
  1. 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.

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 🤔

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.

(that was me, I didn't have git author configured properly from on the system I landed from)

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.