WordPress job boards

Haven’t we all already heard the question “Where can I find a job with my WordPress skills”? If you didn’t, well, I have received this question a lot on different local slacks.

With the increasing number of WordPress sites all over the world, the request for help increases equally. So instead of copy/pasting some sites, I decided to put them together on a nice page so it can serve all of you: http://wp-info.org/jobs/

Send it around, make all WordPress experts aware that there is still work to do ūüôā

 

As always, if you find any other job boards, or if you have any specific remarks, feel free to add a comment to the page or to this post.

Pascal.

Setting up a new locale… Where to start?

Introduction

The ease of creating a¬†new locale, i.e. a WordPress in a new language, is one of the main powers of WordPress. It’s great for the target group to have WordPress in their own local language. But it requires a group of people to do the work, needs time and lots of cold (or hot, depending on where you live) drinks.

Being a GTE, I want to highlight in this post some personal experiences, some decisions that need to be taken, the caveats and the possible ways of getting there.

Requesting the new locale

First step is of course to make a request to setup the environment of the locale. This part is clearly explained in the handbook, so start reading on https://make.wordpress.org/polyglots/handbook/translating/requesting-a-new-locale/

If the request is accepted, you will become the first GTE (Global Translation Editor) of the newly created locale.

For the remainder of this post, let’s consider to have requested ‘anl‘ as ‘a new locale’.

Your team

Finding people is crucial, finding the correct ones even more, so choose wisely. Do not stick with IT guys, you need people that know about translation. If they have a good technical background, that’s great, but don’t forget the translation will be used by people at home that do not always understand tech-talk!

How to get in touch?

Email and one-to-one calls might be a start, but after a while you will need more. WordPress uses Slack as its main real-time communication platform, so a local Slack seems to be a great way to have quick meetings, discussions or stay in touch with each other. Slack is webbased, but also has apps for iOS and Android, so you can join the discussion from everywhere. A list of existing Slacks can be found on http://wp-info.org/slack/ . Creating a new Slack (free if you accept the limit of 10k messages) is easy and straightforward on https://slack.com/create .

Note: Use your @chat.wordpress.org address and as Slack admin, only allow those addresses to join. If you don’t have an address like that, check it out on¬†https://make.wordpress.org/chat/

Your guidelines

Make sure everybody will translate in the same way. An important tool is the style guide for your locale where you can define things like : translation will be formal (or informal), typographic rules to follow, etc.

Examples of existing style guides can be found on  https://make.wordpress.org/polyglots/handbook/tools/list-of-glossaries-per-locale/

Your glossary

Make sure to have consistency throughout your WordPress, plugins and themes translation. So a glossary is the way to keep consistency. If you want to have it centralized, use the one on translate.wordpress.org. Check the link of the glossary of other locales on https://make.wordpress.org/polyglots/handbook/tools/list-of-glossaries-per-locale/ and adapt the URL to point to your own glossary. Any GTE can create a new glossary or adapt words.

But before adding translations in the glossary, there will probably be discussion on the best word in the local language. Most of the current locales use a google doc for new words that need to be decided on. A (2-)weekly meeting to discuss them, decide and add to the glossary seems to be a great way to go.

Decide your translation roadmap

If you have your glossary and guidelines, it’s time to start translating. But where to start?

You will have to decide what you want to do first. Start with one or the other, but do both before moving on:

  • Translate¬†the site (anl.wordpress.org) to attract more people, create the community (like links to existing meetup groups), etc. This is the Rosetta part under ‘Meta’ (https://translate.wordpress.org/locale/anl/default/meta)
  • Translate WordPress so people can download the localized version in their own language. Start with the most reason version and decide how far backwards you want to go in the versions:¬†https://translate.wordpress.org/locale/anl/default/wp

Then you choose the order of the translation the remaining parts:

  • The remaining Meta parts (like the Forums, the theme and plugin directories, etc.)
  • The most used plugins and themes
  • The apps for Android and iOS

Note: Start from zero?¬†If you have created a locale that is very close to the language used in an existing locale, it could be useful to export and import existing translations and then go over every string and modify where needed. It saves a lot of time, but as a courtesy, don’t forget to mention it somewhere in some credits ūüėČ

OK, all set!

Congrats, you should be up and running now!

Now build you translators and give PTE (Project Translation Editor) rights to people that you trust can deal with translations of specific plugins/themes.

Have regular (online) meetings to discuss things and, as GTE, be available to answer questions.

Dear Polyglots, the past is the past

The 4 hour intervention of Matt in the international #polyglots channel last Thursday came as a surprise to all of the people connected at that moment. Since that moment the different local slacks are full of question marks and guesses in the different translator channels around. Is it because some major plugin builder has difficulties with the current structure? Or is it that Matt wants to apply Mode 2 of the so-called BiModal IT to bring innovation?

The current way polyglots are working to get the translations ready for the end-user does not really differ from e.g. developing WordPress Core: Anybody can propose changes (Core e.g. via Trac, Translation directly in GlotPress), others are validating (Guest committers are called PTE for translation) and if you show what you’re worth and doing good, you can become a Core committer or GTE.

The main question was about the bulk import for top plugins that have a professional translation service (or outside of the centralized one). So why a single account would not be allowed to upload translations cross-language. Matt specified that “There are no code audits, so why would we have them for translations. We don’t need everything to be process and rule driven — there can be exceptions when the context and situation warrants”. The proposed way forward was “as in the PTE and GTE model, there’s not a *TE for someone who can approve across locales, I think that is what’s worth trying, in a whitelist approach. But we’d know pretty quickly, and just like in code you can roll things back pretty easily.”

The reply of the Polyglots was that “Quality is the main concern here. Users (clients) will blame poor translation on their developer and the platform. They‚Äôll say that WordPress is low quality, unprofessional. Mistakes will be much harder to fix than prevent. The native speakers that WordPress has as staff, are the PTEs for plugins.” There might still be some bottle necks, but the polyglots community has expanded enormously in the last year(s). Certain locale are adding PTEs almost at a weekly basis so translations get validated and become available quickly. The polyglots team has performed an incredible work so far, and to stay on top of things, they would now benefit from development help to e.g. get notifications, easier process for assigning PTE, translation memory, global glossaries, etc.

But maybe the intervention was all about “rocking the boat”, challenge the polyglots and give them an opportunity to become the most agile part of WordPress by switching from pre-moderation to “trust and then verify” to keep the rules agile? In this innovation model it’s okay to mess up and fail (fail is First Attempt In Learning, right?). As Matt put it: “It’s cathedral vs bazaar, a fear of mistakes outweighing agility and speed. We can get really locked in past decisions. All of the concerns are based on hypotheticals rather than actual experience trying it”. This view seems to be globally shared with other companies that don’t want to just improve or expand existing processes. Try something completely new and different and see what comes out of it. If 2 out of 10 things succeed in this new way, you can already call it a success! If it’s not as expected, roll back.

For sure whatever the reason behind the sudden appearance of Matt was, Polyglots will now sit together, setup a trial phase with a limited number of participants, probably for a limited time and then evaluate if the goals like better quality, more coverage and/or better user experience are reached.

To be continued…

How to get a translation to full validation

Introduction

After my post of last week about the issues as plugin author and how to see the light in translation, the saga continued. On different channels on both global and local slacks, PTE and author requests seem to be the topic of the day. Below is my interpretation of how the translation handbook could be improved for the sake of clarity.

As example I go for the great bbPress plugin and translation into Dutch and French for Belgium.

Proposed improvements

For the translations meta handbook

  • The below Q&A is what a plugin author/contributor wants to know (based on the questions I see), so this might be brought¬†more into focus.
  • In the ‘Can I bring them over‘ part, add the link to polyglots¬†where the words ‘make/polyglots’ are.
  • In the ‘Can I bring them over‘ part, the ‘List of requests‘ link is looking for the ‘editor request‘ tags, but your tag policy says that it should be ‘request‘.

The first link that is found on the translation page of the plugin (e.g. https://translate.wordpress.org/projects/wp-plugins/bbpress) is to the Translator Handbook. It is valuable information, but not what a plugin author is looking for as a start. The more interesting links are (in order of how to read):

Q & A

Global notes:

  • A GTE is a human that acts¬†on translations¬†in his/her spare time. Everybody is a volunteer here!
  • Every locale has it own rules for validating and granting the PTE roles.

Q1. I am a plugin author and have my own translators that could validate for certain locale

  • Add a request on¬†https://make.wordpress.org/polyglots/ (for an example, refer¬†to the Rosetta handbook¬†)
  • Make sure you tag it with ‘request’ and with the locale involved, e.g. ‘request, fr_BE, nl_BE’
  • Follow up the request as GTE will add replies here.

Q2. I am a plugin author and look for somebody to translate my plugin in locale nl_BE and fr_BE

  • With the number of plugins constantly increasing, a¬†GTE will only be validating your translation if no PTE can be found when time permits, not performing¬†the translation itself.
  • Head over to the team of your locale (https://make.wordpress.org/polyglots/teams) and try to ping contributors or PTE of other plugins to see if they are willing to help on slack.
  • Personal note: Most plugin authors are adding a link to the translation page of their plugin (e.g.¬†https://translate.wordpress.org/projects/wp-plugins/bbpress/) as a sticky post on their support forum and/or on the settings page of the plugin. Anybody can contribute to a translation if interested. The main task of the plugin author should to be to code correctly and get the plugin ready for translation, not doing the translation itself.

Q3. I am a plugin author and my plugin is at 100% for locale nl_BE

  • If you translated it yourself, request to become a PTE following the answer in Q1.
  • If somebody else translated it, ask that person if he wants to become PTE and follow the answer in Q1.

Q4. I am a plugin author and have .mo / .po files, how can I have them uploaded

  • Follow the answers in Q3. A PTE in a certain locale can perform the upload if it was not done automatically after the last commit of your plugin

Q5. I am a contributor and have translated all the strings for plugin bbPress in fr_BE

  • Great job. Now ping the author of the plugin to inform him/her of your job. Best way is that the plugin author follows the answer in Q1, indicating your name.
  • If you don’t get an answer from the plugin author, you can try to ping one of the GTE of the locale¬†(on slack) and see if they are willing to¬†help you.

Author Plugin Issues

Introduction

I have started this thread because for a developer, getting the first plugin translated is not an easy task as the process seems to be no so transparent and scattered over tens of pages (if you get to the correct links).

Current situation

A plugin author is a¬†developer, so I just love the¬†logical way. I¬†understand IF this THEN that and how to make sure to get the system working in a great way as you (as an end-user) want it. So when I¬†develop a plugin (let’s take https://wordpress.org/plugins/bbp-toolkit/ as an example), it’s normal to look for a button on the plugin page called ‘Translate bbP Toolkit’ and … Yep there it is. But behind that button there is just text with links to more text containing other links.

Process Steps

If the process needs to be explained, start from the following questions:

  • How do I change my code so it’s ready for other languages? Give me the basic function(s) or tell me where in the readme file or the header of the main php file I need to apply changes. Can I find examples and explanation of how it works ?
  • How can I ask my friends to help me translate, where do they need to login and where do they add the translation (what guidelines to follow). How do I get help from global translator editors for general questions
  • How does my translation gets ‘ready-for-use’, so when do others get it and how ?

My difficulties

  • The very first link you get when entering the translation environment is : “New to Translating WordPress? Read through our Translator Handbook to get started.”, but that one points to a very global page¬†https://make.wordpress.org/polyglots/handbook/tools/glotpress-translate-wordpress-org/ that is not a starting point from a developer point of view. This one:¬†https://make.wordpress.org/polyglots/handbook/rosetta/theme-plugin-directories/¬†was much more appropriate on the practical side
  • Why, when a language reaches 100% it is not automatically activated, so why wait for a GTE to validate it, can I not just accept for my own plugin?
  • What can I do with my existing .po files? Why is there not an automatic upload?
  • Some strings were automatically translated, nice, but it seems I should not change them ? Because if the translation of a word or sentence is ‘universal’, so across WordPress and all plugins?
  • How can I get to a GTE with a question? I found the teams, so if somebody is available I might bother them, but not sure if this is the right way to go. If a translation is at 100%, how to ask to validate ?
  • I can be a PTE for my own project in the languages I speak or understand. Fair enough, but one depending on the language for some it’s sufficient to ask and you get it, for others it’s a kind of quick chat and in some cases it’s close to a university entry exam?
  • What if a locale gets to 99%, then a new version arrives and adds 20 strings? (There answer seems to be that you need to reach ONCE at least the 100%, then you don’t loose your translation, see this example)

Some ideas (from myself but also found on different forums)

  • Add a sticky message on your plugin forum to ask for help in translation
  • Use a different tool for getting the requests for translation. I don’t think tat make.wordpress.com is the best place
  • Explain better (or define) the upload process for po/mo files
  • Every locale should have an updated glossary for basic words (I know some have them!)
  • For smaller plugins, code update speed might be more important then translation, so the original (english) text could be accepted amongst the translation for the new features. Options: Don’t use translation, use best available translation, only use 100% translations
  • How about Opt-in per plugin/project: So e.g. at least 90% of a locale needs to be available, then the plugin author can decide to use that 90% and use the original for the rest?
  • How about auto-validating waiting translations for all plugins that are e.g. over 90% translated?
  • How about lowering the 100% translated threshold?
  • Create a form on the plugin or on the translation pages to send a request to the locale for validation of the project/plugin?

Biography

I’m European, 5 languages on my CV and over the double of programming languages, so yes, I’m into languages! I fell in love with WordPress about 2 years ago when I started to help out with the parents association of the school. You can find me mainly helping out people on the bbPress forums when I’m not busy professionally.