Open Bug 785107 Opened 12 years ago Updated 8 years ago

Implement localization support for Mozilla Hacks

Categories

(Developer Engagement :: Mozilla Hacks, task)

Product:
Developer Engagement
Component:
Mozilla Hacks
Platform:
x86
macOS
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: robert, Unassigned)

Details

(Whiteboard: [type:feature] [localization])

We would like to be able to have blog posts localized for Mozilla Hacks, to have community members and others translate the posts in English to other languages.
Unfortunately, WordPress doesn't support multilingual blogs out of the box. There are plugins that add the capability and we've investigated them, but so far haven't found a multilingual plugin that meets our security requirements. So for the foreseeable future we're stuck with one language per blog. However, that's just for true localization, meaning localizing the entire site in a given language. There's no reason you can't post an article in another language even on an otherwise English blog, and simply link to the translation from the original (and vice versa). Of course, translated posts would appear in the stream like any other post, but if there's an introduction blurb like "this is a French translation of [post title]" that might not be a problem.
I understand, thanks for outlining the options. Having it in the same blog post stream RSS feed etc would be far from optimal. Yes, we could make exceptions, but maybe not the best way to go about it. Worth thinking about the options, for sure. Thanks!
A workaround could be to tag each post with the locale, and then change the theme's feed urls and the page loop to filter by tags: http://hacks.mozilla.org/?tag=fr&feed=rss2 <?php query_posts($query_string . '&tag=fr'); ?>
Yeah, we could do some tag/category trickery to keep translated posts out of the visible stream (unless you know how to find them). Or better yet, make a custom post type for translations and they'd be excluded from the stream by default. Another idea: if you expect you'll be posting a lot of translations in a particular language, we could set up another hacks blog for that locale. It would be a separate, self-contained blog, independent of the main blog, so it wouldn't need to be only translations, it could be original content as well. Then maybe some of those posts could be translated into English and posted back on the main blog. So for that, we could probably convert hacks to a multiblog network so you'd have hacks.mozilla.org/fr/ for the French blog, hacks.mozilla.org/es/ for the Spanish blog, and so on. We'd have to talk to IT about doing it, and I'd need to work on making the theme localizable (and we'd have to get localizers on it), but it's certainly a feasible idea.
Luke, It's an interesting approach, and yeah it could work! However, like Craig says, if we believe this will actually be fully used with regular posts and possible other customizations, maybe it's better to take the plunge and have a separate blog. That way, we'd also avoid the risk of lots of legacy tweaks/workaround in regular Hacks for localization (then again, if we build new features, they'd need to be deployed in several places). Definitely worth thinking about!
Component: Website → hacks.mozilla.org
Product: Mozilla Developer Network → Websites
FYI, the French community has opened its own 'hacks' blog where we publish technical articles as well as a few translated articles from hacks.mozilla.org (for example Jérémie 'translates' the articles he writes for hacks.mozilla.org into French). The address is http://tech.mozfr.org/ and there would be no problem in translating more articles from hacks.mozilla.org.
I like the idea to get hacks translated, CCing a few more folks. I think it's been a while since we've done localized content in wordpress, and that wasn't pretty, IIRC. Not sure if Pascal knows more.
Thanks guys! In general, it's not pretty with Wordpress, but we can gain so much more by having it all in the same web site with branding, consistency, metrics, user handling, outreach and more. Our loose plan is to first just have a separate category for other languages than English, thus being able to offer language start pages (with proper URLs) and listing for just that language. It also means that only English posts would be listed at the Mozilla Hacks start page. If this takes off and we get an enormous interest (fingers crossed!) then we can break it out into different blogs, but keeping the branding and URLs from before.
In the past we experimented with the WPML plugin for OpenToChoice http://wpml.org/ I can't say we were happy with the results (site and/or admin panel regularly unavailable, disappearing posts, confusing UI...) but the plugin may have improved since that time, looking at our repos, we used version 1.7.0 of the plugin.
Thanks for the tip/info!
Robert, welcome to the "Design" phase of our development process. It is in this phase that we talk about interface (and in this case, plugin) solutions to implementing the requested change. I see that you have talked much about this already. But given that the last comment was 5 months ago, maybe it would be worth looking at the options again. Anyone have more up-to-date information on the state of Wordpress localization?
A couple of contenders I came across... * http://wordpress.org/extend/plugins/transposh-translation-filter-for-wordpress/ * http://wordpress.org/extend/plugins/qtranslate/ Might also be worth looking at WPML again, if it comes down to it.
Unfortunately I don't know more about any other options or best way to do it. It seems like the simplest way is to: - Hack Categories - Don't show language categories in the start page - Have custom start pages categories for each language category start page
Whiteboard: [selected]
I've tried qtranslate and it feels like duct-tape, but *did the job*. However, there's no good isolation of content, or any kind of permissions for translators. Works well for a personal blog. If you're willing to hack WP as you said (hacking categories, etc), I know there's a few members of the Hispano community that will be very interested in Mozilla Hacks localization and development. Some of them even with WP experience.
Thanks for the insight! What do you mean by no permissions for translators? Do you mean translators can also edit the English version of the article and do other administrative work?
At least on the version I used, and as far as I remember, yes, a translator could also edit the English version. In fact, when editing, you can see all versions on the same page. Their homepage kinda shows it: http://www.qianqin.de/qtranslate/ Maybe we could contribute/collaborate with some plugin author (qTranslate or any other) to add proper permissions as a plugin feature, instead of hacking our own WP installation?
Yeah, I think that would be preferable to starting from scratch. Especially if that's the only major problem.
Priority: -- → P1
Component: hacks.mozilla.org → Mozilla Hacks
Product: Websites → Mozilla Developer Network
Blocks: 854859
Whiteboard: [selected] → [specification-like][type:feature][selected]
Hi everyone, Could Pontoon* be an option? *https://pontoon-dev.mozillalabs.com/en-US/
(In reply to inma_610 from comment #19) > Hi everyone, > > Could Pontoon* be an option? > > *https://pontoon-dev.mozillalabs.com/en-US/ It could be for working with the translations, I assume, but the big issue is how to get it implemented in WordPress, and then resented to the readers.
Bumping down in priority as we continue to do the research. Still want to get this done as soon as possible, but there is some lower-hanging fruit that we can get to first.
Priority: P1 → P2
Whiteboard: [specification-like][type:feature][selected] → [specification-like][type:feature]
Matjaz should be able to help you with Pontoon, CC'ing.
Whiteboard: [specification-like][type:feature] → [type:feature]
Whiteboard: [type:feature] → [type:feature] [localization]
No longer blocks: 854859
Based on long discussions in e-mail threads, meetings and more, the realistic and doable way to move forward seems to be: 1. Create a new Wordpress category for each new language 2. Exclude any language category but English from the start page 3. Exclude any language category but English from the main RSS feed 4. Let each language have its own simple start page, e.g. http://hacks.mozilla.org/es for Spanish, that only lists posts with that language category 5. Detect user locale different than English on the main start page, and inform them about the articles/start page for their locale For #3, the code should be something like this: function myFylter($query) { if ($query->is_feed) { $query->set('cat','-24'); // exclude category with ID24 } return $query; } add_filter('pre_get_posts','myFylter'); I'd be more than happy to work with #1, but need developer help for #2-5. Suggested is also reaching out to Francesco Lodolo (https://twitter.com/flod) for help. Maris, can we do an estimate of the work needed here and see when we can plan it?
Flags: needinfo?(mars)
Severity: normal → enhancement
Priority: P2 → --
:groovecoder, :davidwalsh, given the nature of the work, is this something we want to take on ourselves, or give to an outside contractor?
Flags: needinfo?(mars)
Flags: needinfo?(lcrouch)
Flags: needinfo?(dwalsh)
Robert's idea is reasonable and seems feasible for us to do, but the answer to your question probably hinges on how we want to prioritize my time?
Flags: needinfo?(dwalsh)
Also hinges on how much time we estimate this would take. :) If I were to do it, I would estimate 1 week, assuming the code in comment 23 works.
Flags: needinfo?(lcrouch)
David, if you think this will take just a week to do, then let's try fitting it in now, before starting on bug 991351.
Flags: needinfo?(dwalsh)
Yeah, I think this is feasible. I can probably start next Monday, if that's cool with you!
Flags: needinfo?(dwalsh)
Hey David, change of plans - I just discussed this with Ali, Luke, and Robert in our planning meeting, and we would like to roll this bug up into a larger piece of Hacks blog work, possibly to be done by an outside contractor.
WordPress is our 2nd most popular webdev contributor interest area - it gets 252 views per month. So, I added this to https://github.com/mozilla/mozhacks/issues?state=open with a link from https://wiki.mozilla.org/Webdev/GetInvolved/WordPress. In case someone wants to help us with it before we get to it.
Sorry for the delay in posting this. This is information originally sent via email to Robert in late March, so it's going to come off sounding like 1-to-1 conversation. "I can see this localization being a two part thing. The first part is making sure that the theme/plugin(s) are translated. I don't have privilege to know exactly what plugins you're running, but if they were professionals, then they made sure that their plugins were internationalized and ready to be translated by others. This means that they used gettext and WordPress' tools for gettext on all hard-coded strings that are seen in the browser. Even better if those plugins also provide a .pot file. That way you can provide that file to anyone who will do some translating to generate the human-readable po file and the machine binary mo file. I wager that the hacks.mozilla.org theme was developed in-house, so it's hard to say if it had all of its hard-coded strings internationalized as well. If not, you'll want to have someone go through that and prepare those. More on that at https://codex.wordpress.org/I18n_for_WordPress_Developers The other side of the coin here will be the content that gets input by the people who can access the WP Admin. This is content that will be stored as posts or pages and whatnot in the database. Much easier to translate because whoever it is just types it out in the language of their choice. However, you also want to take the same articles and provide them in multiple languages and let the visitors to the site choose which version they see. It does look like people on the team have tried http://wpml.org/ already, but that's still going to be one of your better bets at this point for a multi-lingual setup. As someone notes in the bugzilla ticket, it has been awhile since it was last tried, and hopefully things have gotten better. I also recommend http://wordpress.org/plugins/codestyling-localization/ to help with translating the .pot files into po/mo files. I also had http://wordpress.org/plugins/wp-native-dashboard/ suggested for easy *admin* language switching for your users. Not sure if this one will be super helpful, but it could provide some value at least. Not sure on a good frontend solution other than PHP cookies that store a preferred language code. Some video resources for information on the topic, just in case you or someone else needs them: https://www.youtube.com/watch?v=fJfqgrzjEis "i18n: Preparing Your WordPress Theme for the World" by Lisa Sabin-Wilson http://wordpress.tv/2013/08/03/shannon-smith-big-in-japan-a-guide-for-themes-and-internationalization/ "Big in Japan: A Guide for Themes and Internationalization" by Shannon Smith"
Sadly, the theme is not internationalized that I can tell. Lots of hard-coded strings without any gettext wrappers.
thankfully, getting the theme strings ready is not a huge time burden, unless you really do have a TON of text to translate.
(In reply to Michael Beckwith from comment #31) > Sorry for the delay in posting this. This is information originally sent via > email to Robert in late March, so it's going to come off sounding like > 1-to-1 conversation. Thanks for adding this in context!
Product: Mozilla Developer Network → Developer Engagement
You need to log in before you can comment on or make changes to this bug.