@MusikAnimal: All the server-side code was given i18n support in https://github.com/MusikAnimal/pageviews/pull/30. Adding i18n support on the JavaScript side is going to be more difficult. It looks like Intuition has an undocumented JS interface, but it doesn't seem quite finished. In particular it seems to be missing the API part. I'm going to ping @Krinkle and see if he has any advice. The other problem is that several parts of the interface come from 3rd party components like daterangepicker.js, Chart.js, and select2.js, which don't seem to have any i18n support. Any ideas for those?

Got some info from Krinkle. Looks like the client-side should be doable also. The only parts that are still sketch are the 3rd party tools such as daterangepicker.js and select2.js (it actually looks like Chart.js doesn't need to be modified). @MusikAnimal, do you think we should fork those within pageviews to add i18n support? Maybe we could upstream the changes afterwards.

For daterangepicker, you can pass in a locale object to change the labels, formats, etc. Check "locale" on the config generator to see examples. Not sure about Select2, but I think we could probably get away with not translating it. It's intuitive enough that the instructional text is just a bonus and not needed. If you're up for forking it and adding i18n then I've no opposition, though!

Commented on the PR... essentially I want to get this other branch merged in before merging in the i18n branch. With the advent of PHP we'll need to rework the views and I think we'll have a lot of conflicts. Sorry for making this so difficult... once we get these two branches in I think any new concurrent development should go more smoothly.

@kaldari Hey! I've merged in the semi-complete topviews app (a sneak peak at http://tools.wmflabs.org/topviews). I now want to work off of your i18n PR to render partials for the header/footer, etc, and adjust the directory structure to accommodate our new PHP setup.

A question... how do we set the language? You said their language preference persists across other Intuition apps. Since we only have English right now, would non-English users have any labels, or does it default to English?

A question... how do we set the language?

It defaults to English, but once we have other json files, you'll be able to change it by setting a cookie. There is a function in Intuition for getting all the currently supported languages. We can use that to create a select list in the Settings if we want to provide a manual way to change the language (other than changing your browser's language setting).

Alright, I've reworked the app to be all PHP views and ditching HAML entirely. The PR is at https://github.com/MusikAnimal/pageviews/pull/31 and I've got it up and running at http://tools.wmflabs.org/pageviews-test I've noticed the PHP version is marginally slower than the static HTML, but that's OK.

So next up is to merge in your changes to that branch and do some final testing, since this is such a major overhaul.

Should we go ahead and recruit some volunteers to do the translating?

@MusikAnimal: I can probably handle the branch merging. Feel free to just reject my current pull request. Once the i18n code is live, I'll register the pageviews tool with translatewiki and we can start having people do translations there.

@MusikAnimal: If you want to temporarily make me a collaborator on the MusikAnimal/pageviews repo that might be easier than having to deal with pull requests and syncs. Up to you though.

@kaldari Done! But for this i18n work let's keep it on the php branch. I want to keep that and the old code separated just during the testing phase. Let me write up the deploy process and then I will add you as a maintainer of toollabs:pageviews-test, and eventually the main app too :-)

@MusikAnimal: Sounds like a good plan!

@kaldari Commented on the PR... (I assume tech talk is better on GitHub, where phab is for general project management). Having trouble getting this running on Tool Labs. I've added you to the pageviews-test service group