It's important that we can reach out to the communities where editors don't speak English and involve them in the process, giving them a chance to propose something in their own language and hopefully have it translated. It means that we need to have messages ready well in beforehand, so they can be translated.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Johan | T175781 Coordinate Technical Collaboration support for the 2017 Community Wishlist | |||
| Resolved | Johan | T175782 Let the communities know they can propose wishes for the 2017 Community Wishlist | |||
| Resolved | Johan | T175783 Prepare and translate messages for the 2017 Community Wishlist: Proposals |
How much can the messages from last year be reused? Even as is, to preserve the current percentages of translation without boring copy&paste.
Given that translations will mainly be relevant for CentralNotice banners if we do it the same way as last year – which I think we will – the year has to be updated, but I don't think anything else really need to change.
Yeah, this was poor planning on my part. Sorry :( Addressing this issue has been on my to-do's since last year. I get the notifications that another translation page was made, and I'm like, "oh yeah, still need to do that..."
For most of the templates, it's only the page title that needs renaming. E.g. "2016 Community Wishlist Survey/Num proposals" ~> "Community Wishlist Survey/Num proposals". I'm not sure if simply moving the page does the job (and you can move all subapges in the same way, in one go)? If not, I can checkout the repo and mass-rename all the messages using a Node script. This all goes on translatewiki, right? If so I can make sure those messages are NOT marked as fuzzy, since the message itself didn't change, just the key.
For the other pages that actually include the number "2016", I'm thinking we should rewrite them to use a variable, not {{CURRENT YEAR}}, right? E.g. we don't want the title at [[2017 Community Wishlist Survey]] to all of a sudden say "2018" when January rolls around. The CentralNotice banner of course can use {{CURRENT YEAR}}.
Mind you also that this year I think we want to have each proposal be it's own subpage. That means we can do proper translations, with the {{TNT}} template, but also we don't run into that annoying issue with edit conflicts and hacky bot-rotation of the proposals.
Regarding translating our templates, including the preload template: After hours of work, I'm going to have to put in my !vote to not do this. The way it works is you have a parent page that's marked for translation. That will supply a value for the {{PAGELANGUAGE}} magic word, which we can pass into the child templates (such as the preload). So in other words, we have to have at least one message on each Category page, even though we don't want to translate anything on the Category page itself. Not only that, but translations for a given language within the templates only show up if the parent page was translated in that language. For example, if we had German translations for the Category header template, the preload template, and everything else that's transcluded on the Category page, you still will only see German if there is a German version of the Category page itself. Furthermore, the bot and an edit filter work by checking subpages of the Category pages. We'd have to hardcode it to ignore /de, /fr, etc., and not assume those are proposals. And as we discussed, newly transcluded proposals also mean you have to re-mark the Category page for translations (even though there aren't any messages!!!). Indeed we could give the bot translation admin rights, but the complexity and amount of coding is getting greater and greater in order to work around these limitations.
This is all really a shame... but I don't see a sane way to make this work. If only there were a magic word to get the interface language (e.g. what I have set in my preferences), everything would be fine. Unfortunately there is not, so we'd have to go through great lengths, including implementing nasty hacks, just to do what is seemingly the most basic things. I have tried to seek help on IRC to no avail, but I'm pretty sure my assumptions are correct and there's no straightforward implementation for what we need.
Overall I don't see this as negligence toward non-English communities, but rather a limitation of the Translate extension and using the wiki as a platform for the survey. I am still all-for encouraging non-English proposals, and we can translate them to English ourselves as needed. I would not enable translations on proposal pages though, as these will not show up on the Category pages.
Sorry I couldn't make this happen! :(
All language versions that's not English now includes the option to create a proposal landing on a different page using a translatable preload, to make sure that the proposal-creating part of the process is not only in English.