Launchpad claims a project uses Translations when it doesn't

[Matthew Paul Thomas]

<https://launchpad.net/firefox> says that Firefox "Uses Launchpad for: ... Translations".

But <https://translations.launchpad.net/firefox> says "The Mozilla Firefox project is not set up for translation in Launchpad."

One of these, probably the former, isn't true. It shouldn't be possible for Launchpad to claim simultaneously that a project uses Launchpad for translations and that it isn't set up for translation.

[Jeroen T. Vermeulen (jtv)]

This is just a transitional state: in terms of stated intent, the project uses Translations. In terms of completion, it's not quite there yet.

[Matthew Paul Thomas (mpt)]

If it was really a transitional state -- for example, if official_rosetta automatically turned itself off after a week of no template being uploaded -- that would make this bug less important, because the false statement would be visible for a much shorter period.

As it is, however, it's possible for me to register an upstream project in Launchpad, check the "Translations for this project are done in Launchpad" checkbox, and then get hit by a bus (or go off and become a monk in Outer Mongolia with no Internet access) and never use Launchpad again. The project page can then continue to falsely say "Uses Launchpad for:...Translations" for decades. (Alexander Sack will soon flip the switch for launchpad.net/firefox, but only because he was available for me to ask him about it.) And the word "uses" is really too common in English for Launchpad to get away with redefining it.

I suggest fixing this bug by changing official_rosetta to a cached value representing whether the project has any uploaded templates, and removing the "Translations for this project are done in Launchpad" checkbox from the project details form. This would make Launchpad more truthful *and* make the project details form simpler. Win-win. :-)

[Jeroen T. Vermeulen (jtv)]

The official_rosetta flag is the direct counterpart of similar options for the other applications in Launchpad. The generic check on the front page checks these flags directly, so the same situation may also arise for the other applications; the Translations page also checks for a series actually having translatable data. If we wanted to do away with the flag altogether, we'd have to disable or remove translations when a project wanted to stop using Translations.

Something we could do without much trouble is to make the text distinguish between "not set up to use Launchpad for translation" on the one hand, and "not fully set up yet" on the other. That would also be a good opportunity to mention the review period for the initial uploads.

[Matthew Paul Thomas (mpt)]

The counterpart flags you refer to are official_codehosting, official_malone, official_blueprints, and official_answers. official_malone, official_blueprints, and official_answers make sense as maintainer-togglable switches, because having them turned off is the only way to prevent random users from entering stuff (bug reports, blueprints, and questions respectively) that would likely be ignored.

official_codehosting, however, like official_rosetta, is currently misleading project maintainers into making Launchpad say untrue things, which is being discussed in bug 256073. As I understand it, the most realistic measure of whether a project officially uses Launchpad for code hosting is not whether official_codehosting is True, but whether Launchpad hosts the project's mainline branch. Similarly, the most realistic measure of whether a project officially uses Launchpad for translations is not whether official_rosetta is True, but whether the project has translatable templates. In both cases, I think making the flag a cached value calculated from reality would make the project page more accurate, and would make those Launchpad applications easier for project maintainers to set up.

I like the idea of distinguishing between "doesn’t use Launchpad for translations" and "is having templates reviewed in preparation for using Launchpad for translations" (and it may make sense to fix bug 119602 at the same time as doing that). That still doesn't require a separate maintainer-togglable switch, though. :-)