WordPress.org

Make WordPress.org

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • 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. :)
  • Samuel Sidler 1:36 pm on July 7, 2015 Permalink |
    Tags: , , , , ,   

    Weekly i18n Chat Notes – July 7, 2015 

    After a four week hiatus (!) we had our weekly i18n chat today. We’ll be continuing these chats every week on Tuesday 11:00 UTC 2015, just like before.

    This week, we discussed the following:

    • Forums: While the bbPress 2 forums aren’t quite ready yet (literally no plugin has been ported to bbPress 2 yet), we’re going to move ahead anyway. @ocean90 is going to work on setting up forums for the Italians within the next week, but is running into permissions issues with bbPress.
    • Translate: @ocean90 implemented most of the @isaackeyet‘s design for translate.wordpress.org. With the new designs, there’s only a handful of technical things left before we can start adding additional plugins or themes:
      1. Finish design implementation: The big piece that’s left is adding the sub-project drop down in the top right box, which is needed to allow switching between sub-projects. Additionally, a green outline needs to be around the box if a project is at 100%, but this isn’t blocking anything.
      2. Paging. Without paging, the list of plugins will grow unwieldy. @dd32 is going to work on paging (which needs to be done here).
      3. Roles Plugin Changes: The roles plugin won’t scale if we add hundreds (thousands!) of new projects. We need a UI here – designers wanted! See #1101.
      4. Search: Not needed for an initial import of the top n plugins, but required for when we add all plugins. We’re putting this on hold for now as paging will suit our needs for the foreseeable future.

    Beyond the technical list above, we need to talk about how plugins will be imported. Let’s chat this Friday July 10 13:00 UTC 2015 about importing plugins into translate.wordpress.org. If you’re interested in this topic, join us in #meta-i18n.

    (As a reminder, all WordPress community meetings are listed on the meeting calendar.)

     
    • Marko Heijnen 3:01 pm on July 7, 2015 Permalink | Log in to Reply

      This was exactly why I asked Matt my question at WordCamp Europe. To me GlotPress is now really a project outside WordPress since you basically forked GlotPress on meta. This because point 1,2 and 4 should have been done though GlotPress.

      On the last note check out some code I wrote https://github.com/markoheijnen/GlotPress-Slurper but it’s best to not write this in PHP.

      I always kept a bit away from #meta-i18n but due the way you guys didn’t communicate and exclude me in any way possible you can do what you want but I’m not helping out.

      • Samuel Sidler 3:26 pm on July 7, 2015 Permalink | Log in to Reply

        Hi Marko,

        I understand your concerns. The design we implemented can easily be part of GlotPress, if you’d like the changes upstream. We’ve attempted to add things to GlotPress in the past that were specific to translate.wordpress.org and were given a lot of pushback for those changes. Fwiw, you’ve said before that you want GlotPress to be separate from WordPress, but your comment here complains that “GlotPress is now really a project outside WordPress.” I’m a bit confused about what you want.

        That said, let me address each change you mention specifically:

        • The design changes we’ve made mimic the look and feel of WordPress.org. You’ve told us repeatedly that GlotPress is not a WordPress project and pushed back when we’ve tried to make such design changes. Thus, it made sense to make these changes specifically for translate.wordpress.org.
        • Paging is specific to the views we’ve created for translate.wordpress.org and will mimic the look and feel of the plugin directory’s paging.
        • No one has started working on search. I fully agree it should be part of GlotPress core. If you’d like to work on it, that would be great.

        I’m sorry that you feel excluded. We haven’t tried to exclude you. The #meta-i18n channel is for anyone interested in the WordPress.org side of these various projects. Will we need to modify parts of GlotPress to meet our needs? Absolutely. And we’ve done so. If you’re interested in helping with those pieces, then definitely join the channel and the weekly chats and participate.

        However, there will also be patches to GlotPress needed – like search, as you mention. If you’d prefer that all of the above changes be part of GlotPress, I’m sure we can commit them in the near future. Just let us know.

        Note that we’re also making changes to other projects as part of this. We have an entire list of bbPress plugins that we’re using to modify bbPress (linked to in this comment) as well as a bbPress-specific theme for WordPress.org. The GlotPress changes we’re making are similar in scope to that.

        • Marko Heijnen 4:22 pm on July 7, 2015 Permalink | Log in to Reply

          My opinion is that GlotPress is a separate project outside WordPress and some of you say it’s a WordPress project. With how translate.wordpress.org is currently managed it seems that you now agree with me.

          I have never pushed back design changes. Only said that I rather wait for it due to things with more priority. I have said that I rather do a complete redesign then only small parts because it’s needed. You can check out the discussions in GlotPress slack channel a few months ago that I really want them to implement it directly in GlotPress and they decided to not do that.

          Paging should be implemented in GlotPress since it’s a code change. How it should then look can then be specified for .org. And I understand/agree if that needs to be done.

          That said, how things are going is understandable. I have heard from people that (core) people have asked them why they want to contribute back to GlotPress. Saying that I’m hard to work with. That is BS to me. I’m a team player as long as the other does the same. Everyone I actively worked with will say that. Problem with WordPress is that own interest seems to blur peoples mind.

          • Samuel Sidler 5:16 pm on July 7, 2015 Permalink | Log in to Reply

            Hey Marko,

            As you’ve said, you think GlotPress should be separate from WordPress. Likewise, you said that design changes should be part of a “complete redesign.” Both of those statements point to the need for us to implement our partial redesign directly on translate.wordpress.org instead of in GlotPress. We prefer to constantly iterate instead of focusing on a complete redesign as we don’t have time or resources to focus on such a large project.

            I assume the chat you were talking about “a few months ago” refers to this chat (that’s just the start of the chat, of course). In that conversation, you’re very adamant that because the discussion is about the design then-proposed for translate.wordpress.org, you aren’t interested in contributing to the conversation and left the chat in the middle of it. It was quite interesting to me that you asked for the discussion to continue in #glotpress and then decided to not participate shortly thereafter.

            That said, you did say that you wanted design changes to happen in GlotPress (not just on translate.wordpress.org) but pointed those in attendance to an empty GitHub repository instead of encouraging the work being proposed. One thing I’ve noticed when interacting with volunteer designers is that many don’t want to deal with committing their work or even writing CSS/HTML. A great way to encourage designers is to offer to build the CSS/HTML templates and commit the changes on their behalf. Regardless, at the time, your actions at that chat left me thinking that you didn’t want the changes on translate.wordpress.org. If the opposite was true, it would have been nice to have a clear statement from you, along the lines of: “These are great changes that shouldn’t be specific to translate.wordpress.org; I would gladly take these changes upstream in GlotPress.”

            Given your comment here, are you saying that you want these changes in GlotPress? I offered twice in my previous comment, but you didn’t respond to the offer.

            For paging, if it makes sense to do in GlotPress, it will be done in GlotPress. Currently, the paging that needs to happen is for a view that doesn’t exist in GlotPress, which is why I made my statement in the previous comment.

            I can’t speak to what “(core) people” are saying about working with you. I can say that if GlotPress wants the design and functional changes from translate.wordpress.org, the meta team needs to hear that from you. If you’re having difficulty with a specific person or people, please ping me privately – on Slack or via email works – so I can address that. If you don’t feel comfortable with that, you can also ping any member of this group.

            It will always be the case that WordPress (and this team) has its own interests at heart when developing translate.wordpress.org. When those interests diverge from the stated interests of GlotPress (that is, your statements), we’ll make changes only on translate.wordpress.org and not in GlotPress. If you disagree and think a change we make should be upstreamed to GlotPress, please let us know.

            • Marko Heijnen 10:51 pm on July 7, 2015 Permalink

              I don’t know in which ways designers want to contribute back. Reason I pointed to GitHub is that it’s easier to work with a big group of people on something. I’m fine with people getting commit access there and work on things. And I believe that it would be easier. This because of the additional CSS things that get loaded on .org.

              About paging I’m unsure which view you mean but it is on my list and have said it during WordCamp Cologne and WordCamp Europe that it is a priority due to the fact that locale & project pages don’t have it yet. So on that one I would love to work together with @dd32 on.

              For other things I would love to know what is going on but with so many channels discussing things, it’s hard to follow what is going on.

            • Samuel Sidler 11:09 pm on July 7, 2015 Permalink

              @markoheijnen:

              In a volunteer-based project, you have to meet people where they are. In this case – as in many cases with volunteer designers – expecting contributions in the form of CSS/HTML isn’t reasonable, so I offered to do that work for them. A GitHub repo – and code contributions in general – would not work well. Additionally, that repo is for contributing an entire redesign, which wasn’t our focus. I’d be interested in an entire redesign (as I said above), but it’s not the priority right now for the meta team. We implemented the things we needed. Further, for our design, we had to pull in icons from the plugin directory, which is very specific to our needs and not a general GlotPress thing.

              As far as paging, we implemented a specific view for “classes of projects” that will need pages (probably need a better term there). For example. That view is not something that GlotPress core has or likely needs. We extended it because it makes sense for translate.wordpress.org. I’m sure @dd32 would love your help adding paging to that view.

              There are only two channels for all GlotPress things: #glotpress and #meta-i18n. The latter is for translate.wordpress.org-specific discussion, though we often discuss overall needs as well. For example, today we discussed a general need for search, which will likely be done directly in GlotPress, but is a need that translate.wordpress.org has in the not-too-distant future. Just because we mentioned that we will need it in #meta-i18n does not mean that is where it will be implemented. There are no other channels that you need to follow if you want to know what’s going on with translate.wordpress.org.

              All of our code changes are in meta svn. All of our tickets are in meta trac.

    • Caspar Hübinger 5:26 am on July 8, 2015 Permalink | Log in to Reply

      I just want to say it’s really an encouraging experience to finally notice all the progress being made on wordpress.org. The incremental redesign, the improvements to Rosetta sites, forums and everything—for whatever reason I had failed to notice a lot of it for some time, but now I do, and it really makes me glad. You meta guys (are there even ladies on that team?) rock!

  • Sara Rosso 3:55 pm on July 6, 2015 Permalink |
    Tags: contributor day, marketing, wceu   

    WCEU 2015 Contributor Day – Marketing group notes

    This is the 2nd time we’ve had a Marketing contributor day group at WCEU, and the 3rd I’ve led (also at WCLDN) We had 15 people join the Marketing day group, which was double that of last year’s group, and I heard from several people that they weren’t sure they would be able to contribute on Contributors Day until they joined, so that was great.

    We worked on 3 main things:

    • Furthering the open source WordPress presentation started at WCEU 2014
    • Generating a list of ideas for other marketing contributor day groups to tackle
    • Re-imagining the Features page on WordPress.org

    Open Source WordPress Presentation

    • If you haven’t heard about it, it’s a reveal.js presentation (i.e., manageable on GitHub, platform-independent, easily modifiable by anyone who knows HTML) incorporating a lot of the reasons and selling points I’ve shared in some of popular enterprise presentations at WordCamps. The idea of this presentation is to help agencies and freelancers ‘sell’ WordPress and they can customize it to their market / country with a great set of starting examples and case studies, and focus more on building sites vs. selling WordPress.

    We came up with an outline at WCEU 2014 and the outline is almost complete for me to get a first draft online in a Github repo. With the work we started in 2014, I took some personal/work time to further it between meetings, and will continue to do so. We made some progress on the open source and multilingual sections.

    Marketing Sub-group ideas for Contributions
    We took 10-15 minutes to brainstorm some ways that we could contribute back to the Community and here are a few things we came up with:

    • 1-page datasheet/flyer about WordPress features
    • Information banners with infographics
    • Comparison charts of different CMS
    • 1-page summary of the WordPress ecosystem (or a map/graphic)
    • Infographic about security? non-technical
    • Benefits of open source
    • Redesign features page
    • Modular Landing page for presenting WordPress
    • Redesign tag landing page tempate for .org Showcase with tag description/intro
    • Country-specific landing pages (aka tag landing page) for .org Showcase

    Re-imagining the Features page on WordPress.org

    This was a fun exercise to try and we broke the group up into two teams so they could work together, faster. We were lucky to have some UX designers in the group, and each team took a different approach. Here are their suggestions below, one focused more on content and addressing the three audiences we believe are addressed/interested in this information (user/content creator, administrator, and developer), and the other focused more on the display of information.

    I did preface the exercise by saying I wasn’t guaranteeing we could change the page, but I think it’s a good exercise for the community and it would be nice if we could update it – some of the content is rather old, like highlighting “ability to have comments.” :)

    I’m not able to post pictures, so you can check out the gallery I uploaded here on GDrive of the team and their landing page suggestions:
    https://drive.google.com/folderview?id=0B9wRJsOfSKgzflJJVkNiaFFreXpqOEJKcGFnUDlqUTNHcDVSeTkyMWV5blpFdDJzbDFfSGc&usp=sharing

     
  • Ian Dunn 7:44 pm on June 16, 2015 Permalink |
    Tags: git, sandbox,   

    Editing WordCamp.org CSS Locally with Git 

    Over on make/Community, we’ve been discussing ways to eliminate some of the worst pain points that WordCamp organizers have with building their sites.

    There’s one discussion in particular that I’d love to get feedback from Meta team members on, which is determining the best way that we can support a traditional development workflow.

    Right now organizers have to edit the CSS for their site in Jetpack’s CSS editor, which is painful because it wasn’t intended for the kinds of use cases that we have.

    Instead, we want to allow organizers to build their sites in a local sandbox, managing the code with Git, and be able to easily push updates to production.

    If anyone is interested in giving feedback or helping to build the tools we need, please check out the discussion.

     
    • George Stephanis 7:46 pm on June 16, 2015 Permalink | Log in to Reply

      Possible way to do it would be to roll in an xmlrpc endpoint or json api endpoint or something that they can use to push the local source up to the wordcamp site? Seems like that’d likely be the easiest solution.

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar