Topic on Talk:Technical Collaboration Guidance

Keegan: Reading the current draft, I think you might be over-confident about getting things translated.

In Technical Collaboration Guideline/Translation, you say that there's two steps -- getting translations and distributing translations. I think that first step is actually two steps -- marking a wiki page for translation, and then getting people to translate it. Marking a page for translation is a tricky process to learn, and if I remember it correctly, you need a special user right to do it.

Once a page is marked for translation, things get a bit tricky -- updating the page means that messages need to be re-translated, but it's a judgment call about when the change is significant enough to ask people to re-translate. You also run the risk of burning out the volunteer translators.

So I think the guideline on Technical Collaboration Guideline/Milestone communication might need some more nuance. :) Right now, it says "translations must be had if an announcement is being made that concerns projects in languages other than just English." That's a very broad guideline that potentially puts a great deal of work on the translators' to-do list. Can we make that more specific, or offer a best practice like "once a month/quarter, you should have at least one announcement/update that's marked for translation"?

In general, I'm very happy to see the emphasis on early communication and openness with the community -- more on-wiki discussion, publishing early wireframes, etc. It's hard for product managers and designers to get used to that -- in most other settings, you don't show people your ideas until you've polished them up a bit. So more guidance/expectations-setting/support for that will help a lot.

Great feedback on the Translations, very helpful. I'm stuck on that page and this helps me think it through.

I think there's another good point here about it being hard for managers and designers to get used to the early exposure of their ideas. It would be easy to just brush it aside saying, well Wikimedia projects aren't "most other settings" but I think we can go a little deeper. The content contributors work like that all the time. Content is published and immediately exposed to scrutiny, review, criticism and so on. So the content contributor community are used to that and not going to be sympathetic to the notion that designers wouldn't want to work like that. It is also true that content criticism is widely felt to be somewhat draconian, and that might explain why interactions between that community and the designers and coders can get rather bumpy. However, what we need to do is manage that interaction into productive channels, not shy away from it. It really is important that we get this right and make it a productive and stimulating, if not always comfortable process.

Yes, I agree. This takes product managers and designers out of our comfort zone, but I think it's important to do that. We need to be more comfortable publishing early ideas and sketches.

Thanks, you two, and more importantly thanks for bringing up one of the underlying issues. It gets me thinking about how we can turn this into something in the future. Much appreciated.

Just to follow up on that, I would suggest that most projects would or should be co-created with the community of users. The notion that developers evolve ideas for new products or functionalities in isolation from the needs and wishes of the community, then deliver them fully formed to a grateful but essentially passive public I think only needs to be articulated to be discredited. And yet this is how some of the major rows between the Foundation and the Community have arisen.

I disagree with this idea that the devs – most of whom are volunteer devs, just like most Wikipedia editors are volunteer editors – aren't part of "the community of users". If you meant this only to refer to those devs paid by the WMF at the moment, then I'll point out again that some staff devs are admins on the projects and make thousands of content contributions each year. Over the years, about half of the WMF's staff and more than half of the (volunteer and staff) devs have come straight out of "the community of users".

But even if you define paid devs as no longer being users, in reality, if you're an admin at Commons in your volunteer capacity, and you're working on Multimedia in your staff capacity, then your software project is never going to be developed "in isolation from the needs and wishes of the community". It is not at all unusual for product teams to have devs with advanced user rights and to be intimately familiar with at least one of the affected communities. VisualEditor and Collaboration have several Wikipedia admins; Multimedia and Parsing have at least two at the moment; Language's PM is a volunteer admin at seven different public projects. The dev teams often look first to the communities when they have a job opening, and the result is that many devs are community first, and staff second.

I do not believe that a developer also being a user means that there is no necessity for engage with consult the wider community when formulating requirements, designing software or planning project. Ido not accept that it is unnecessary for a developer to look further than their own personal experience or inclinations when starting up new ideas. It is clear that while some, even many, developers may also be users, the vast majority of users are not developers, and so their views, wishes and needs are not represented by this navel-gazing approach to software design. If you think that the overlap between developers and users is in itself sufficient to eliminate the need for any further effort to engage users in co-creating software then you must have been sadly disillusioned by such projects as Media Viewer / Superprotect, Gather and Knowledge Engine. It is clear that users and developers are different roles, and while enacting those roles people have different views, adopt different attitudes and take different sorts of action. The communities are distinct, with different venues, discussions modealities and cultures. Rather than pretending all is well (since it obviously is not), it is better to articulate those differences and explicitly address them, evolving proecesses that can be used to co-create effectively and productively

On the translation issue, I can see that there is a load here. Is it possible to lighten that load by technical means? We are not talking about formal translation processes for stable documentation that needs and deserves high-quality translation for a product of long-term value to all language communities, but a "good enough" tool that can give a reasonably accurate rendering into some subset of the major working languages in close to real time for the purpose of discussion and planning. This would be of quite wide application here and at Meta, I would have thought.

On translation load and quality of translations, note that translation engines may be used in MediaWiki.org, currently with the Apertium engine enabled. Just like volunteer editors and translators are driving the use of this tool and translation engines in other wikis, they could also do it here.

Once a ok-ish translation is available in a language, it is easy for the readers of that language to polish it if there is enough interest -- a factor that relates to the relevance or popularity of a specific announcement.

I do not know how well machine translation works between "major working languages", but last I checked, translation for e.g. Swedish, and especially Finnish, was mainly a joke (you may get an idea of what is discussed, but you won't know what view is supported). If trying to "polish", the language usually stays ugly, and important errors may pass unnoticed. Translating from scratch gives better results, often with less effort. I suppose Arabic and Chinese are as hard as Finnish to get right, if translating from English.

As a native Catalan speaker I understand very well the challenges of most languages versus automatic translation engines. Still, the overall picture is not as bad if we add translation memory to the mix, another feature supported by our translation tools and available in MediaWiki.org.

The first time that i.e. "Try out this new beta feature!" is posted in a translatable announcement, translation engines will help some languages more than other, and manual translation will help nurturing the memory in all languages translated. The second time that sentence is used in another announcement, all that memory will be available in the languages that were translated to once, and volunteers will just need to click once to get the translation offered.

This means that a new recommendation is emerging: write announcements in a structured, modular way, recycling as many components as possible. This might sound boring and mechanic to some, but actually makes it a lot easier to get an announcement translated to many languages and therefore reaching more and more diverse users.

I also bet that native English speakers would welcome a more concise, structured and predictable approach to tech announcements, even if it comes at the expense of some individual style and creativity.

Getting translations for brief announcements isn't usually difficult. But translations for whole pages is less likely to happen, and getting timely updates is particularly unlikely. There are many VisualEditor pages that were translated in mid-2013 and haven't been touched since then.

Using structured data (=an infobox) helps, because you can translate the template once and get some automatic updates. It's also helpful to write a basic introduction or a {{nutshell}}-like summary for the project in Simple English, and to request translations for that.

However, using Extension:Translate to mark up a page is going to discourage people from updating the page. It moves the documentation from "the product page that anyone can edit" to "the product page that almost nobody can edit, and nobody does".

Hence my suggestion for a technical solution that would at least alleviate some of the burden.

All this calls for a reasonably consistent approach to project documentation and updates, which is a good thing in itself, regardless of translations.

How should the regular documentation of a project look like? This is how I see it.

• Project information page. Acts as landing page, provides basic information for all audiences and links to the rest. Translatable. It has an infobox and default structure of sections to be defined. The emphasis on translations is put in the infobox & first section, which should contain the most basic information and links to updates. All the rest is nice to have.
• Milestone subpages. The TCG recommends to communicate around milestones. There would be a list of recommended milestones: project idea, beta...) and each of these milestones would have its own page for modular documentation and focused discussion. These pages would be in English, feedback in other languages in their discussion pages would be accepted.
• The announcements about new milestone / milestone completed would be open for translation. Here is where the focus on structured language may make life for translators a lot easier. Imagine i.e. a template for a Design Review announcement, where the moving pieces are the project name, the short description (translated already in the project info page), the URL of the review, and the specific dates of the timeline.
• User Help pages, which already have a translation process.
• Developer documentation pages, which is OK to have in English only.

With such structure, translations would be focusing on

• Project intro and infobox
• Milestone announcements, based on templates.

The rest would be based on the translators' interest in translating further, but would not be as critical in terms of missing basic information and updates.

Great discussion, all. It sounds like when I re-write the translation page, there are some issues and opportunities to outline with our translations processes. Examples include: while accepting machine translations, keep in mind that they probably need a human eye at some point (though, aside from recruitment, that's out of one's control in a volunteer environment), the longer a message gets, the harder it is to have translated, burnout, to name a few. I can take many of these points to a higher level after I think about it a bit.

Thank you all, more comments in this or any other/new section are always appreciated.