Make WordPress.org

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Samuel Sidler 4:19 pm on September 22, 2015 Permalink |
    Tags: , , , , , , , ,   

    Weekly i18n Chat Notes – September 22, 2015 

    Earlier today a handful of us gathered to talk about life, the universe, and things that may or may not relate to the meta team and i18n. Here’s a bit of what we talked about:

    • Plugins: Last week imported our first set of plugins into translate.wordpress.org! Hurrah! Huzzah! 🎤⬇️ And because we were feeling good about it, we also sent out emails to the second batch of plugin authors (~200 plugins). That import will start today or tomorrow and we’ll send out emails for the next import soon.
    • Translate: The stats page got some love with the addition of the Waiting column (see #1202) and some improvements to the design (see #1238).
    • Theme Directory: @obenland started work on the Translations section by adding a link to translate any theme to the page. Check out the Twenty Sixteen theme page for an example.
    • WordCamp: Set things up so the WordCamp theme can be translated (see #1076), pending deployment by the WordCamp team.
    • Forums: There was a mention that the Italian forums are not working. @ocean90 will investigate. Additionally, we’ve had a couple of requests for new forums. We think it’s okay to add new ones for testing purposes. For example, an RTL forum would be appropriate.

    For the next week, we’re planning to work on the following:

    • Import and language pack status of plugins sent to a Slack channel.
    • Sorting / Filter UI finished up (or whatever we call it).
    • Streamline the process of adding per-project translation editors (see #1237 which requires #1240).
    • Work on updated design for project pages in Translate.
    • Possibly: More Theme Directory translation section additions.
    • Possibly: Rosetta headers fixed up (see #1201).
    • Possibly: Job system started.

    See y’all next Tuesday at 11:00 UTC!

  • Samuel Sidler 6:01 pm on September 15, 2015 Permalink |
    Tags: , , , , , ,   

    Weekly i18n Chat Notes – September 15, 2015 

    We met today, like normal, at 11:00 UTC and discussed the following things:

    • Translate: Warnings on translate.wordpress.org are now being sent to #polyglots-warnings for more transparency and to catch bad actors. (The channel name may change to #polyglots-notices to cover other usages.) Additionally, the “Waiting” tab now shows the full project name instead of just the sub-project name; e.g., “Plugins – Akismet – Development (trunk)” instead of “Development (trunk)” which was less descriptive.
    • Plugins: Last week, emails went out to the first batch of plugins. We are ready to begin the import into translate.wordpress.org.
    • Forums: @clorith has taken on a plugin! We love new contributors. :)

    There was no update last week (on this blog) but we also improved the design of the stats page.

    Over the next week, we intend to do the following:

    • Plugin import, starting today.
    • Import and language pack status of plugins sent to a Slack channel.
    • Emails for next plugin import batch will go out.
    • Sorting / Filter UI finished up (or whatever we call it).
    • Possibly: Rosetta headers fixed up.
    • Possibly: Jobs system started.

    See y’all next week!

  • Samuel Sidler 5:07 pm on September 7, 2015 Permalink |
    Tags: , , , , ,   

    Weekly i18n Chat Notes – September 1, 2015 

    Howdy! We have our weekly i18n chat tomorrow at 11:00 UTC. Please join us.

    Last week, we discussed the following things:

    • Translate: A stats dashboard has been created. We’ll track the most important projects on this dashboard. We still need to add a couple of features for admins. A bit of time was spent on ways to improve the dashboard and, if you attend tomorrow, you’ll discover that a number of changes were made.
    • Meta Environment: Not a normal topic for us, but a pull request exists that adds translate.wordpress.org to the meta environment so developing for it will be easier.

    What’s up for the next week’s worth of work? Maybe some of the things mentioned here.

    At the end of the chat we mentioned that we’re on track to start importing plugins in ~2 weeks. Since I’m posting this about a week late, that means next week we plan to begin the plugin import.

  • Samuel Sidler 12:32 pm on August 31, 2015 Permalink |
    Tags: , , , , , ,   

    Weekly i18n Chat Notes – August 25, 2015 

    As a reminder, we have a chat tomorrow at 11:00 UTC. The update below is from last week’s chat

    It’s been a while since we last met! I think WordPress 4.3 somewhat distracted us. :) Here’s what’s happened in the last three weeks:

    • Forums: Progress has been made on porting bbPress 1.x plugins! So far, @jmdodd has migrated two plugins to bbPress 2.x. If you’re interested in helping out, be sure to put your name in the “Migrate?” column of the table. (Need access? Just ping me.)
    • Translate: A “Waiting” tab now exists and both it and the themes tab is now sorted by the order previously discussed. Filters are still coming (pending design), but we’re well on our way. Additionally, themes are now in sync with the directory and fully caught up. That means if a theme is approved in the directory, it is automatically imported into translate.wordpress.org.

    And upcoming:

    • Sort orders (and filters) in translate.wordpress.org.
    • Properly log warnings in translate.wordpress.org to a Slack channel so we can keep an eye on them.
    • Fixes to \r in translations.
    • Rosetta header changes.
    • An i18n dashboard to keep track of major products.
    • Automation of Rosetta deploys (pending logging mentioned above).
    • Job / queue system for imports and language pack generation (with systems).

    About a month ago, I made a list of next steps before importing plugins to translate.wordpress.org and we’ve done them all, but run into a few other things needed (as listed above). That said, I think we’re very close to the point where we can import plugins. Of the items above, only the job system is necessary, due to the number of commits plugins receive. More to come on make/plugins.

  • Samuel Sidler 10:01 pm on August 7, 2015 Permalink |
    Tags: ,   

    Translation Project Sorting / Filtering 

    As a follow up for my earlier post on translation project sorting and compiling the comments/thoughts therein, I think we should start with the following things, in order by priority for implementing them.

    1. Waiting Tab: It’s clear that translation editors need a tab just for waiting strings. This tab should be default for translation editors unless there are no waiting strings, in which case WordPress should be the default tab. If a user is only a translation editor for one project, it will show here. If a user is a translation editor for many projects, all will show here using the default priority sorting (see #2). If a user is not a translation editor for any project, they should not have a waiting tab.
    2. Default Priority: With every tab, we need to establish a default priority, however the themes and plugins tabs will need it most. I propose the following default priority: Favorites, strings remaining (“0” goes to the bottom, “1” to the top), and by popularity. That means that your favorites will display at the top of the list, unless they have been fully translated. Further, if 10 plugins have two untranslated strings, all 10 will appear at the top of the plugins tab, in order by popularity, but below your favorites. Once a project is completely translated, it moves to the very bottom of the list, regardless of favorite status.
    3. Filters: Within each tab, we need to ability to filter by the following things:
      1. Favorites
      2. Popularity within the directory
      3. Strings remaining (toggle between most/least; perhaps a “completed” option as well)
      4. Percentage complete (toggle between highest/lowest; perhaps a “completed” option)
      5. Waiting strings present in project
      6. Fuzzy/warning strings present in project
    4. Future Filters: In the future, we should consider the following filters:
      1. Waiting age, especially on “Waiting” tab (aka, projects with strings that have been waiting for two weeks will appear before projects with strings that have been waiting two days)
      2. Release date for themes/plugins (aka, most recently updated first)
      3. Hide/show fully translated projects

    How does that sound to everyone?

    P.S. I’m out for next Tuesday’s weekly chat, but feel free to meet without me!

    • Stephen Edgar 10:21 pm on August 7, 2015 Permalink | Log in to Reply

      Sounds good, thinking about “fuzzy” strings, I’m thinking they may be best also included in the “waiting” tab, fuzzies usual turn up as a result of machine based actions rather than human, there are typically not many of these but I’d weight these fuzzy strings higher in priority than any waiting strings.

    • Caspar Hübinger 10:27 am on August 8, 2015 Permalink | Log in to Reply

      Makes perfect sense imo. +1 what @netweb says.

    • Adrian Pop 3:44 pm on August 10, 2015 Permalink | Log in to Reply

      Excellent! Can’t wait to use them! :)
      @netweb – good point! Translating the fuzzy strings usually decrease the waiting strings remaining to be translated by the same amount. So fuzzy strings must be before the waiting ones.

  • Samuel Sidler 4:43 pm on July 29, 2015 Permalink |
    Tags: , , , ,   

    Weekly i18n Chat Notes – July 28, 2015 

    A few more things were discussed at this week’s meta i18n chat:

    • Translate Themes: Just a couple of things:
      • All active themes were imported! But syncing hasn’t been enabled yet so a few newer themes (since the start of the import) are not yet imported. They will be soon, don’t worry. :)
      • Language packs were enabled for themes! If a theme does not ship with translations and is fully translated into a language (in translate.wordpress.org), a language pack will be generated and automatically downloaded. Woohoo! Language pack generation is automatic. When a theme is fully translated (100%) in a language, a language pack will be generated. Some history from @ocean90:
        • 2010 – First language packs for importers
        • 2011 – Core ticket #18200 filed
        • 2013 – Ticket #18200 closed as fixed (WordPress 3.7)
        • 2014 – Language packs enabled for core (WordPress 4.0)
        • 2015 – Language packs for third-party plugins and themes (WordPress 4.3+)
    • Translate Project Prioritization: I’m working up a detailed list of what we should do and when, based on the post from last week (and comments). Design-wise, we’re going to stick with what exists in the theme directory and modify as necessary.
    • Translate Import Queuing: There’s a lot of projects that will be added and syncing. We’re going to work up a queueing system in case things get overwhelmed. This is needed before we start importing plugins.
    • Rosetta Header: We need to “fix” the Rosetta header with the static, known sections, allowing Editors to add on at the end of it. Since we don’t have a showcase except on the homepage, my proposal is to set the following menu items: Home, Themes, Plugins, Forums (if they exist), Blog. Editors will be able to add additional menu items.
      • (Note here that we should really add the Download button to the Rosetta headers as well.)

    Over the next week, we’re going to continue to improve themes on translate.wordpress.org, including language pack work and synchronization. If there’s time, we’ll also start adding filters / prioritization to projects.

  • Samuel Sidler 5:10 pm on July 21, 2015 Permalink |
    Tags: , , , , , ,   

    Weekly i18n Chat Notes – July 21, 2015 

    At our weekly chat today, we talked about a few things:

    • Forums: The Italian forums were launched! It’s a bit rough around the edges, so there’s a bunch of work still left to do. If anyone is interested in contributing to our bbPress theme just let us know. The more help we can get, the faster we can get the forum theme in shape to launch it to other locales. (Big props to @ocean90 and @medariox!)
    • Translate: Tons of things going on and upcoming here.
      • Themes are being imported. Currently ~1100 out of a total of ~1900 themes. The rest should be imported by next week’s meeting.
      • As part of the import, we’re noticing that quite a few themes have a textdomain that is different than the theme’s slug. Language packs will not support that. Instead, we’ll contact theme authors and work with the theme review team to ensure this won’t happen again. (Also, @Otto42 is adding modifying theme-check so that it checks for this issue.) Some stats on that were shared in Slack, but note that they’re for all themes, not just active themes. The actual numbers will be different.
      • Meanwhile, we need to start considering how to sort and prioritize themes and plugins. This post has some ideas and the comments section is open for more. We should have a list to start on by next week’s meeting. There are some backend changes that @dd32 needs to work up first.
      • One method of prioritizing is favorites. @dd32 is working up changes to the theme directory (and elsewhere) so themes can be favorited. ❤️ We can use theme and plugin favorites to prioritize projects (per-user) on translate.wordpress.org.
      • @ocean90 is also testing plugin imports with a few select plugins to ensure the import script works well.
      • Additionally, the language pack script currently exists for plugins and will be modified for themes (thanks @ocean90!).

    Most of our focus right now is on language packs and theme/plugin translations. Summarized, here’s the next steps:

    • Finish theme import
    • Enable theme directory syncing (every new/updated theme gets imported)
    • Implement some prioritization (including a side project: adding favorites to themes)
    • Modify the theme directory to support translated theme names/descriptions
    • Enable language packs for themes
    • Start importing top n plugins
    • Enable language packs for top n plugins

    Of course, some of these will happen in parallel with others and there are numerous parts to each line item, but we’re making great progress. By next week, we’ll probably be able to cross off an item or two. 👏

  • Samuel Sidler 5:33 pm on July 20, 2015 Permalink |
    Tags: ,   

    Translation Project Sorting Ideas 

    We’ve been collecting some ideas for sorting all of the projects that are being imported (themes and plugins). I want to collect some of the ideas here, along with my thoughts on them. If you have other ideas, we’d love to hear them!

    • Prioritizing by popularity: Projects could be organized by how popular they are, that is, how many users and/or downloads they have. For translators, the projects that are used the most by users are often considered the most important.
    • Prioritizing by fewest strings remaining: If a project is almost complete – e.g., just a few strings away – it can be considered higher priority. By enabling this option, we’d give translators a way to complete more projects faster. Personally, I think this is better than doing by percentage because 1 string remaining in a project of 10 is fewer than 10 strings remaining in a project of 1000, despite the latter being a lower percentage.
    • Prioritize by permissions: If a translator is the translation editor for a specific project – or a few specific projects – we could show those projects first, since they have permission to approve translations for that project.
    • “Hide” fully translated projects: If a project is fully translated and strings are fully approved, we could “hide” those projects or at least put them at the very bottom of the list. For themes and plugins, this will put them on the last page of results. Searching will still find them, of course.
    • Starring or Favoriting: Everyone has one or two themes/plugins that they really love and want to see available in their language. Giving translators the ability to “favorite” a project and have it raise to the top would make it easier to keep track of new strings in their favorite projects. We could even create a new “tab” for “Favorites” that could be the default if a translator has favorites.
    • Sort by waiting: Translation editors should be able to see which projects have waiting strings so they can approve them. Within this view, we should probably prioritize projects based on some of the ideas above.
    • Improved search: Translators should be able to search by author name (theme or plugin) and see a list of their projects, for example.
    • Consider “alerting” when changing a translation: It’s hard to explain this, but if I, as a translation editor, change the translation of “gallery” in one project, GlotPress should alert me to the fact that other projects have a translation of “gallery” that is the “old one” and possibly even offer to update all projects with the new translation.

    The ideas above are just that: ideas. We may not implement any of them or all of them. But it’s important to list them and think through how we can improve the translation experience.

    What other ideas do people have on sorting, prioritizing, and generally improving the translation experience of translate.wordpress.org?

    • Stephen Edgar 1:52 am on July 21, 2015 Permalink | Log in to Reply

      Great summary of ideas Sam… I like all of them, though that isn’t the most helpful constructive feedback 😉

      Another view:

      • “Fuzzy/Warning” similar that of the “Sort by waiting” view (possibly even extending that view) to include fuzzy/waiting, for context I’m thinking, if a thing is 100% translated but has just acquired a fuzzy/warning string for whatever reason these strings would be of a higher priority to get said thing back to 100%

      Alerts: I think this is needed no doubt, I’m sure I’ve seen a locale or two mention that the same word can be used for multiple things but has entirely different meanings, I cannot remember of the top which locale it was but I’m sure it was in regard to the word `post`, so if indeed that is the case then changing that string globally across projects would not be a desired outcome.

      More thoughts as they come to mind…

    • Dion Hulse 5:16 am on July 21, 2015 Permalink | Log in to Reply

      Starring or Favoriting: Everyone has one or two themes/plugins that they really love and want to see available in their language.

      Perhaps we can simplify this by bringing Favourites to the theme directory, and then re-using the users favourites plugins/themes for this view within GlotPress. I guess we could also add a favourite-this-item action within GlotPress which just marks it as favourited on their respective sites too.

      • Stephen Edgar 6:01 am on July 21, 2015 Permalink | Log in to Reply

        I like this idea… Looking at my favourite plugins now, trying to work out if any on my list I wouldn’t want listed as a plugin I’d want to translate… Nothing stands out as a reason against this.

        Maybe a couple, though that’s because I’ve fav’d them as a reminder to install them to test and have a look around rather than them actually being a favourite, maybe that would be a good reminder to actually check them out or remove them from my favourites.

      • Dion Hulse 9:52 am on July 21, 2015 Permalink | Log in to Reply

        Obviously the above is only applicable to the Plugins/Themes tabs.

        It starts to become tricky when someone might want to have their favourites list multiple things, for example, Theme/TwentyTen & WordPress/Dev.

        One angle might to be to NOT have a favourites tab, but instead simply have the Themes/Plugins views float the translators projects & favourites to the start of the list. If they have validation over 1 theme specifically, that’s the first on the list, then their 5 favourites, then all the others.
        For a language validator (ie. who has no per-project capabilities) then it’d simply show their favourites first, then everything else.

    • Jeremy Herve 10:07 am on July 21, 2015 Permalink | Log in to Reply

      I like most of these suggestions. I can’t think of any other view right now.

      Sort by waiting: Translation editors should be able to see which projects have waiting strings so they can approve them. Within this view, we should probably prioritize projects based on some of the ideas above.

      Within this view, how about showing the projects with the oldest pending strings first? This way we’d make sure translators don’t get frustrated because their suggestions are “ignored”.

    • Adrian Pop 11:10 am on July 21, 2015 Permalink | Log in to Reply

      I love all these ideas. I think Favorites shoud be the first to be implemented – and definitely linked with the ones in my w.org account.
      As for sorting purposes, I would love to have something like this – a second bar under the main (search) bar with direct filters:
      Strings ↓ | Percentage ↓ | Waiting | Fuzzy | # | 0 | A | B | …. X | Y | Z | Author:

      Another idea is to have a button in the plugin page name to jump in the plugin’s available translations page, or to have a box with all the languages available (50% or more) each with a link directly to that translation project: DE, FR, RO, RU, etc.

    • savione 1:27 pm on July 21, 2015 Permalink | Log in to Reply

      All the ideas are great. I would like to have something like this:

      • Sort by popularity (this view is basic for me)
      • Sort by fewest strings remaining (including waiting and fuzzy)
      • Sort by oldest waiting
      • Sort by latest realease (date of last update)
      Filters = show only projects where:
      • I am translation editor
      • The project has waiting/fuzzy strings
      • The project is NOT fully translated (hide fully translated)
      • I contributed to the translation (this would help people helping with translation of specific projects)
      • savione 11:21 am on July 22, 2015 Permalink | Log in to Reply

        I forgot about the starring/favoritig. That one can be filter as well.

        The best part about filters is that I can combine them and get different use cases.

        1. Show only projects that are not fully translated and are amongst my favorites. And then sort by… (translators)
        2. Show only projects where I am translation editor and with waiting/fuzzy strings. And then sort by popularity. (translation editor)
        3. Show only projects where I contributed to the translation and are not fully translated. And then sort by fewest strings remaining. (translators)
        …and so on

    • Petya Raykovska 8:54 am on July 22, 2015 Permalink | Log in to Reply

      Thanks for the writeup, Sam. As a couple of people already mentioned, all of them would be highly appreciated.

      We’ll make sure more polyglots read this and leave ideas here. I would definitely like the ideas that @savione and @adrianpop mentioned implemented.

      Love the “Favourites” idea.

    • tareiking 10:37 am on July 22, 2015 Permalink | Log in to Reply

      I’d like to see both personal and team-wide favorites. If may be possible that a team want to focus on a few popular plugins.

      Editors could then show via favorites where the teams focus and attention is being placed currently, like a ‘state of the word’ for upcoming projects.

  • Samuel Sidler 10:50 pm on July 14, 2015 Permalink |
    Tags: , , , , , ,   

    Weekly i18n Chat Notes – July 14, 2015 

    We had our weekly chat today and talked about a few things.

    • Forums: We’re still waiting for one issue to get fixed in bbPress before we can enable initial forums for the Italian community.
    • Translate: Lots of great progress.
      • Design implementation is done.
      • Paging is done. Basic search is part of it as well.
      • Import scripts are done for themes and in-progress for plugins.
      • @dd32 tested an import of all themes and it works! 🎉
      • Role plugin design changes are still pending, but the design is ready, so it’s just a matter of implementation.

    Because of the progress on themes, we think we can do the initial import for themes very soon. It’s know that there will be issues, especially in categorizing and sorting through all ~1500 active themes that will be imported. We’ll work through those issues, fix them, and be ever-more ready for plugins.

    Also, because we’re so close, I posted on make/polyglots and make/themes to give them the heads up and added some documentation to the translator handbook to walk through how some of this will work on their end.

    As we get closer to the initial import of plugins, there will be a post on make/plugins and we will email plugin authors ahead of time, with a specific date, so they have an opportunity to commit any missing translations to SVN.

    (See also: the meeting notes from last week.)

  • Samuel Sidler 11:02 pm on July 10, 2015 Permalink |
    Tags: , , , ,   

    Plugins, Themes, and Translate.WordPress.org 

    As mentioned a few times, we’re going to be enabling the translation of active plugins and themes in the WordPress.org repositories on translate.wordpress.org. Today, we had a chat in #meta-i18n (logs) about how the non-technical side of this will work.

    As a quick recap: We’re making good progress on the relevant pieces of Rosetta, GlotPress, and all the related scripts needed to import plugins and themes that are in the WordPress.org directories into translate.wordpress.org and make them available for translation. Every plugin and theme will then be able to take advantage of languages packs, meaning no more delay in language updates and smaller plugin downloads.

    Here are a few of the points we discussed on how this process will work:

    • Eventually, all active themes and plugins in the WordPress.org directories will be imported into translate.wordpress.org and made available for translation. The “eventually” is important to note as we will be importing a few at a time to ensure GlotPress can scale accordingly. It’s also important to note that “active” is a theme or plugin that has been updated in the last year. Further, even plugins and themes that are not i18n-ready will be imported so that their descriptions can be translated.
    • Additionally, any plugins or themes that do not live in the WordPress.org directories will not be allowed on translate.wordpress.org. For example, commercial plugins.
    • During the initial import, we intend to import all strings – included translations – directly from the plugin’s svn repository on WordPress.org. We will not continuously import these strings, however. Ideally, after the initial import, a plugin would then delete the strings from the svn repository, making their download smaller and immediately taking advantage of the language packs generated by translate.wordpress.org.
    • For a language pack to be updated, the string must be updated in translate.wordpress.org.
    • The above point means that if a theme or plugin author uses a different site for translations, those translations must be brought over to translate.wordpress.org. If the theme or plugin has an active translation community, they can work with the polyglots team to bring translation editors over to the community. These translation editors can be limited to specific plugins, at the discretion of the locales translation editors. These translation editors can import strings for the plugin/theme, should they wish to continue using a different site for translations. (When we get closer to this, I’ll create a sample post that theme and plugin authors can use.)

    That’s a lot to take in, so please let it digest. :)

    One thing we also discussed was the possibility of enabling GlotPress installations to “talk to” each other, such that translate.wordpress.org could import strings from another GlotPress site (for example, translate.yoast.com), whether as a feature of GlotPress core or a plugin. Currently, this is an open question. We plan to discuss the technical questions of this possibility at next week’s #meta-i18n chat (Tuesday, July 14 2015 11:00 UTC). Note that we will not wait for this feature before continuing with our planned import.

    A few other notes:

    • We discussed the possibility of adding a banner to the specific plugin/theme’s page on translate.wordpress.org pointing the external site where translations are active, should a plugin/theme not use translate.wordpress.org as the canonical source for their translations. Currently, I believe the answer is “no banner” but it’s a conversation we should have and re-evaluate over time.
    • Outside of that, it occurred to me after our chat that we will need to add translation editors to the relevant theme/plugin page. For example, if a translator editor only has permissions to approve translations for Hello Dolly, we should note that on the Hello Dolly page within translate.wordpress.org. Example: “Strings for [project name] are approved by the German translation editors [link], as well as username, username, and username.”

    If you’re interested in any of this topic, we’d like to get some feedback on any/all of the above. Please leave your comments here, not in #meta-i18n, so others can see your feedback. We’re especially interested in feedback from plugin and theme authors who do not currently have translations and one’s who use an existing product for their translations.

    • Stephen Edgar 11:24 pm on July 10, 2015 Permalink | Log in to Reply

      Great write up, thanks Sam, will go read the chat transcript now :)

    • Nile Flores 12:19 am on July 11, 2015 Permalink | Log in to Reply

      Great! That is an excellent idea about getting other GlotPress to talk to each other. We’ve completed WordPress SEO over at Yoast and a few others in several languages.

      • Stephen Edgar 12:53 am on July 11, 2015 Permalink | Log in to Reply

        I think this is an interesting comment in the context of “Translator Community”, and I think we will see more examples of this, they are not explicitly Yoast translators, they are translators and are community agnostic.

    • Jeremy Herve 9:59 am on July 11, 2015 Permalink | Log in to Reply

      Great! I’d have a few questions about the whole process.

      1. Once the translations live on translate.wordpress.org, will new .mo files be generated every time a new string is approved, or will translation files be attached to a specific version of the plugin?
      2. How will validator permissions be handled? If you’re a translation editor already, will you automatically get validating permissions on all the plugins on translate.wordpress.org, or will that be limited to plugin authors only?
      3. As a plugin author, will I be able to import / validate strings in just about any language?
      4. As a plugin author, will I be able to grant validator permissions to specific WordPress.org users for my plugin, or is that something I’ll have to request on make/polyglots?

      Thank you!

      • Samuel Sidler 6:53 pm on July 14, 2015 Permalink | Log in to Reply

        Good questions! Here are some answers:

        1. Plugins can maintain two branches within GlotPress: stable and development. If a new string is added to either, it will update in GlotPress and show that string as “untranslated.” Once the string is translated, a new language pack will get generated and users of that plugin, on that branch will get the new language pack.
        2. There are two kinds of translation editors on translate.wordpress.org: Editors and Translation Editors. The former can approve strings for any project across all of translate.wordpress.org, for their language. The latter can be set with per-project permissions, thus can only approve translations in the projects they’re approved for… which can be all projects or any sub-set of projects. (See also, the polyglots handbook.)
        3. Plugin authors do not automatically get rights to approve strings in any language. They will have to request permission from the translation communities. Note that we strongly recommend that translation editors for any plugin be able to speak and understand the language they’re approving. e.g. If a plugin author doesn’t speak Japanese, they shouldn’t be able to approve strings in Japanese. In practice, this is entirely up to the individual translator community.
        4. You will have to request it on make/polyglots. This handbook page talks about how.
        • Jeremy Herve 7:49 pm on July 14, 2015 Permalink | Log in to Reply

          Plugin authors do not automatically get rights to approve strings in any language. They will have to request permission from the translation communities. Note that we strongly recommend that translation editors for any plugin be able to speak and understand the language they’re approving. e.g. If a plugin author doesn’t speak Japanese, they shouldn’t be able to approve strings in Japanese. In practice, this is entirely up to the individual translator community.

          In the past, I would sometimes receive an .mo file from someone using a plugin of mine, who was nice enough to translate it into their language and send me the translation files back. How will I handle such cases once we all use translate.wordpress.org? I’d like to be able to important strings that are sent to me by some of my plugin users.

          • Samuel Sidler 10:23 pm on July 14, 2015 Permalink | Log in to Reply

            You can forward that on to any translation editor of that locale.

            In practice, this isn’t an ideal situation because they’re unable to see the work of other translators and take into account the standards (read: glossary) that the team has set, so your plugin’s translations may feel “off.” Your plugin also can’t benefit from the work of the translation community which may correct errors in any given translation.

            However, there will always be occasional situations like this. Either they can become a translation editor for your plugin and upload it on their own, or, as I said, you can forward the translation on to a translation editor.

            • Jeremy Herve 8:56 am on July 15, 2015 Permalink

              That makes sense. It also means a lot more work for translation editors and for whoever will have to answer all the requests on make/polyglots. Especially in the beginning, it could mean multiple posts from lots of plugin and theme authors on make/polyglots.

              Once I start releasing updates for my plugins, what should I do when I see translations pending validation for some languages? Should I post on make/polyglots to ask translation editors to review all strings before the release?

            • Samuel Sidler 6:35 pm on July 20, 2015 Permalink

              @jeherve: If you’re bringing your translation editors over, I recommend pinging them directly, since you already have a relationship with them. At the moment, only the mobile team, core, and bbPress/BuddyPress post on make/polyglots for that reason. However, we could just improve the views so that projects with a lot of waiting strings are at the top of the list. (See also.)

    • Valerio Souza 1:21 pm on July 13, 2015 Permalink | Log in to Reply

      Good if you need plugins for testing, I have some that use another platform for translation.

    • Zach Tirrell 3:17 pm on July 13, 2015 Permalink | Log in to Reply

      We currently use GlotPress for translations, very much following the setup Yoast has. http://translations.theeventscalendar.com/

      A few questions:

      1. how much control / responsibility will plugin authors have around managing their translations and translators on translate.wordpress.org?
      2. currently we package up translations and push them to SVN, but the GlotPress translations we have are fresher. Can we get you to pull those instead of what is in SVN?
      3. we do have existing translators, how can we go about getting them setup on translate.wordpress.org? It’s not many, so a manual process would not be terrible.
      4. we would certainly be interested in a feature where GlotPress installations “talk to each other”. We have commercial plugins in addition to the ones we publish on WordPress.org, so allowing our plugin translators to all work from one place could be nice.

      I’ll plan to attend the #meta-i18n chat.

      • Samuel Sidler 6:58 pm on July 14, 2015 Permalink | Log in to Reply

        (I edited your comment to make it an ordered list so that I can reply to it easier.)

        A few answers:

        1. Plugin authors cannot add/remove translation editors or import translations. They will need to post on make/polyglots with a list of users who should become translation editors for their plugins. Translation editors can import translations. See this handbook page.
        2. Ultimately, we’ll import whatever is in SVN. Because we’ll be contacting plugin authors before they are imported, they will have an opportunity to update SVN before the initial import. Doing this manually for many projects doesn’t scale, which is why we prefer to do this based on the contents of SVN.
        3. The details are on the link I gave you above. They can’t become translation editors for your plugins yet, because your plugins aren’t yet imported. But as soon as they are imported, you can request permissions for them. However, for base-level translators (aka, people who translate but do not approve translations), they only need a WordPress.org account to get setup.
        4. You were present for the discussion today. :)
compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar