Page MenuHomePhabricator

Register pageviews tool with translatewiki.net
Closed, ResolvedPublic3 Estimated Story Points

Description

Once the i18n code is merged, we will need to register the pageviews tool (http://tools.wmflabs.org/pageviews/) with translatewiki.net so that we can start getting translations. We should also set it up to automatically push the translations to the GitHub repo.

Event Timeline

DannyH set the point value for this task to 3.Mar 3 2016, 6:34 PM
DannyH moved this task from Bug backlog to Up Next on the Community-Tech board.

According to @Nikerabbit, we need to supply a logo, label, and short description.

Logo: https://translatewiki.net/wiki/File:Pageviews_Analysis.svg
Label: Pageviews Analysis
Description: Pageviews Analysis provides visualization of pageview statistics for Wikimedia project pages.

Here are some examples of new projects being added to the TranslateWiki repo:
https://gerrit.wikimedia.org/r/#/c/272492/
https://gerrit.wikimedia.org/r/#/c/270813/

Nikerabbit renamed this task from Register pageviews tool with TranslateWiki to Register pageviews tool with translatewiki.net.Mar 4 2016, 6:33 AM

All set! The PHP branch has been merged and deployed :) If you want to handle setting up translatewiki.net that'd be awesome. I'm going to try to clean up the views one last time... possibly moving back to HAML. Shouldn't interfere with your work. Many thanks for the help!

Change 275131 had a related patch set uploaded (by Kaldari):
Adding Pageviews Assessment project to translatewiki.net

https://gerrit.wikimedia.org/r/275131

Per https://github.com/Krinkle/intuition/wiki/Migrate, https://gerrit.wikimedia.org/r/237193 might be a good example. I don't know the exact translatewiki.net configuration myself, either.

GitHub users @Nikerabbit and @siebrand need to be given push access to the repo.

@siebrand Which repo are we talking about?

The repo the strings live in, and translations have to be added to. I assume that's https://github.com/MusikAnimal/pageviews?

@siebrand Yes I believe they will in https://github.com/MusikAnimal/pageviews/tree/master/messages. However would a pull request not suffice? I'd prefer to restrict push access to active maintainers.

would a pull request not suffice?

Nope

Pardon my lack of understanding. Just did some reading and see that you are both staff members that handle integrating with git repos, on behalf of other volunteer translators? No problem, then :) That makes a lot more sense, just didn't want to have to grant access to each individual translator, understandably. I've added you both.

Whenever you push, you might see Travis CI complain about the build failing, just ignore it. I haven't got it working yet with our new PHP setup, but either way it doesn't apply to the translations. Thanks!

@kaldari Thanks, I was wondering where we were with this. Do you need a code review on that commit? Are we waiting for the translatewiki team to merge it?

@MusikAnimal: Yeah, basically waiting for Niklas (from the translatewiki team) to get back from vacation, which should be next week.

We also need a project page like https://translatewiki.net/wiki/Translating:Crosswatch (among the things I don't know: whether there is a suitable component on phabricator).

Change 275131 merged by jenkins-bot:
Adding Pageviews Assessment project

https://gerrit.wikimedia.org/r/275131

@Krinkle @siebrand @Nikerabbit I see that some translators are putting in {{PLURAL}} as in the MediaWiki magic word. This syntax is not recognizable by Intuition/PHP and errors out such that you get a blank page. Is there a way we can ensure it is not added moving forward? Or maybe there is some pluralization functionality that Intuition offers?

I see that some translators are putting in {{PLURAL}} as in the MediaWiki magic word. This syntax is not recognizable by Intuition/PHP and errors out such that you get a blank page. Is there a way we can ensure it is not added moving forward? Or maybe there is some pluralization functionality that Intuition offers?

Does this provide any answers? https://github.com/Krinkle/intuition/wiki/Documentation#user-content-message-functions

It does, thank you. I guess we'll need to decide which messages might involve pluralization, as I assume there's some performance factor here or else it would always parse for magic words.

Please don't worry about performance unless you are processing thousands of messages. It looks like that API got some inspirations from the old messaging system from MediaWiki before we enabled magic word parsing the default.

If you are passing variables that already is a strong hint that parsemag is likely needed.