WordPress.org

Translate WordPress

Updates from July, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • Petya Raykovska 12:40 pm on July 15, 2015 Permalink |
    petya • bg.wordpress.org editor
    Tags:   

    Notes from the Polyglots chat on July 15th 

    • All TE of locales with language variants, please write a request on make/polyglots for the option to be added for your locale. Requests should include a slug (like `formal`), the english and native name of a variant.
    • Let’s document the different language variant usecases we have now, @alvarogois, @dimadin @gluekpress, could you describe your particular usecase and how you have handled things prior to this?
    • A quick reminder you can translate 4.3 strings in the development project now. The teams page shows the progress of locales on the 4.3 dev branch. This, as mentioned last week, will also give you the opportunity to test translations if you have the beta tester plugin running in your install
    • Themes and Plugins are coming to the repo (https://make.wordpress.org/polyglots/2015/07/14/translating-themes-and-plugins/), minimal requirements for TE to be added as per project validators:
      • Description including projects and locales they’re taking care of
      • Slack name (unless limited by a technical issue)
      • Other means of communication – email, twitter or other social account 
      • Gravatar
    • Plugins and themes who do not want dotorg translations (language packs from translate.wordpress.org) can “opt-out.” The way for them to use their own translations, instead of ones from translate.wordpress.org is to… do nothing. Or, to keep doing what they’re currently doing. Translations that are shipped with themes/plugins take priority to language packs. WordPress will use them first and not download the language pack.

    • We’d love the accessibility team’s input on these requirements – Taco to pint Rian for her opinion
    • The process for plugin/theme authors to request external validators for their plugins/themes to be added is described in https://make.wordpress.org/polyglots/handbook/rosetta/theme-plugin-directories/#requesting-new-translation-editors
    • Handbook updates: In august Petya will organise a handbook sprint for all handbook pages that have been reported to have issues. To help this process along, you can either report issues (slack or make/polyglots blog) or if you want to get involved more, request to be added as an editor to the handbook. The translation sprint will have tasks outlined for everyone who wants to join in to claim and work on. 
    • Polyglots team volunteers – with a lot more people joining the polyglots community, we need all the help we can get to help people with locale requests, questions, new validators orientation, documentation. If you’d be interested in helping out with any of the tasks below, please raise your hand in the comments:
      • Answering people’s requests on the polyglots P2
      • Doing locale research for new locale requests – includes checking the request on the p2 and communicating with the person requesting the new locale, ensuring the ISO-3 codes are correct, adding information about how many people speak the language, double-checking plural forms, creating a ticket on the GlotPress track with all the information needed to add a new locale. (You will be trained by Petya)
      • Monitoring feature requests/bug reports from polyglots and filing those as issues on the meta track

     

    Cheers!

    Petya

     
    • Alvaro Gois dos Santos 2:37 pm on July 15, 2015 Permalink | Log in to Reply

      Thanks @petya. As to variant usecases, you want us to describe them here?

      • Petya Raykovska 3:33 pm on July 15, 2015 Permalink | Log in to Reply

        Yes, Alvaro, let’s get them all here and we can work out how to add them to the documentation after.

      • Alvaro Gois dos Santos 9:07 am on July 20, 2015 Permalink | Log in to Reply

        In pt_PT we have 3 language versions: default, which is formal (and old orthography), informal (also old orthography) and the new orthography formal, not yet in GlotPress.

        The Portuguese Language Orthographic Agreement of 1990 (AO90), the new orthography, is being implemented for 5 years now, with huge resistance in Portugal and several other Portuguese language countries. It’s mainly a political decision, with little respect for history and some basic rules. Nevertheless, it’s being used byimposed to public institutions. There is still hope that this Agreement is rectified, if not disposed, at least to eliminate it’s most absurd flaws.

        A while back we had a discussion in the Portuguese WordPress Community regarding the adoption of the AO90. The vast majority said no. But now the question arises again, and it seems unfare, even if we still have a strong resistance, that there was no alternative for those who wanted or needed to have WordPress in accordance to AO90. On the other hand, it’s not fair either to automatically update an orthography (with a new WordPress version) for thousands of users without their consent. That’s why, in the meantime, we came up with a plugin solution for this: PT Variants.

        There’s also the issue of maintaining two versions (three, if we include informal, which has almost been an one-man-project), regarding consistency of terms and available resources. There’s software that can automatically convert old to new orthography, therefore, consistency can be kept in the current form. But the ideal way, IMO, would be to integrate variants in GlotPress in a side-by-side flow. Since only some of the strings actually differ, it would be easier to maintain variants this way, using the default version as a fall-back for not yet translated or equal entries.

        • Samuel Sidler 1:08 pm on July 20, 2015 Permalink | Log in to Reply

          I can see why that feature would be ideal for you. There aren’t very many locales with variants, however. Speaking for the meta team, this isn’t something we’re going to spend time on as there are other, higher-priority things that we need to work on, which affect all (or most) locales.

          If someone from the Portuguese community wants to work on this for GlotPress, I’m sure we would enable it on translate.wordpress.org shortly after the feature was committed to GlotPress.

          • Alvaro Gois dos Santos 5:20 pm on August 24, 2015 Permalink | Log in to Reply

            Thanks @samuelsidler (and excuse my late reply). I’ll see what @pereirinha has to say about this. I have no clue how this is/could be done.

            As to the variants discussion itself, I’m not so sure there aren’t many more variants. Probably they aren’t used because we had no infrastructure to address it until now.

            • Samuel Sidler 5:58 pm on August 24, 2015 Permalink

              Perhaps, but I think we would have received requests for them over the years. :)

    • duytrung2121 12:27 pm on July 18, 2015 Permalink | Log in to Reply

      Hello Petya!
      I see bbPress support many language but without Vietnamese, So, can you add Vietnamese to bbPress project to translate? Thank you.

    • Milan Dinić 10:37 am on July 21, 2015 Permalink | Log in to Reply

      Here is description of Serbian case as mentioned in the meeting.

      Why we have this? Wikipedia says that “Serbian is practically the only European standard language with complete synchronic digraphia”. What that means is that both Cyrillic and Latin script are used, one letter from Cyrillic can be transliterated to Latin and vice versa, they are pronounced exactly the same, and that every Serbian speaker understands both.

      Automatic transliteration from Cyrillic to Latin is practically 100% safe. Theoretically you can do that from Latin, but in reality that is not an option because you can use Western words like ‘WordPress’ or typos like c, č, ć (in Cyrillic quite different ц, ч, ћ) etc. That is one of the reasons why texts that should be available on both scripts (like translations) are made in Cyrillic and then automatically transliterated.

      That is what plugin in /dist does, when turned on, simply replaces each letter from Cyrillic to Latin thus enabling Latin translation. It was proposed on mailing list (thats why Finnish guy made it, wasn’t that into WordPress then) more than seven years ago since otherwise we would have another locale to maintain which is completely same, only difference is writing system.

      Since ditching of /dist is announced, I have thought about how to solve this. What shouldn’t be done is starting new locale and treating it as a separate language as it’s really not. Problems are that no human can manage this as there are many projects with same repetitive work done, confusion for users as to where to contribute, many unfinished or duplicated work in both sides, many wasted time and energy, etc.

      I think that @nacin first mentioned idea that I am more toward it, especially when formal variants are introduced. That is doing work on wordpress.org that would make language pack for Latin from Cyrillic translations on the fly.

      So how would this work:

      • Create new code, lets name it sr_RS@Latin for now, that is only exposed through API, so it would appear in dropdowns in WordPress but no separate locale site or GlotPress projects.
      • Create language packs from GlotPress exports as usual. When sr_RS is processed, also create language packs for sr_RS@Latin from the same base using code like in our plugin to automatically transliterate. Save additional data about package if needed for API.

      This way users could switch to that variant and stop shipping plugin with each release while it will still be untouched on older installations so we would have backward compatibility.

      I know that this involves some work on meta side (I would gladly contribute but that part is private, I think), but is far less than having two locales, and it’s the only idea I can get right now. Other proposals are welcome.

    • Alvaro Gois dos Santos 3:04 pm on August 25, 2015 Permalink | Log in to Reply

      You understimate the power of WordPress ad-hoc translation… 😉

  • Alvaro Gois dos Santos 8:43 pm on May 19, 2015 Permalink |
    alvarogois
    Tags: AO90, ISO, Portuguese Language Orthographic Agreement, , , variants   

    Hi Polyglots,

    I’m a validator of the Portuguese (pt_PT) translation team. We’re facing a major issue with our translation. Some of you may have heard of the Portuguese Language Orthographic Agreement of 1990 (AO90). Well, it’s being implemented for 5 years now, with huge resistance in Portugal and several other Portuguese language countries. It’s mainly a political decision, with little respect for history and some basic rules. Nevertheless, it’s being used byimposed to public institutions.

    A while back we had an internal discussion in the Portuguese WordPress Community regarding the adoption of the AO90. The vast majority said no. But now the question arises again, and it seems unfare, even if we still have a strong resistance, that there’s no alternative for those who want or need to have WordPress in accordance to AO90.

    Therefore, what I need to discuss with you is the possibility of having variants for the Portuguese language, despite Portuguese in Portugal having only one norm. Me, @ze-fontainhas and several other members of the Portuguese Community have long discussed this possibility and how to implement a solution. Since there are no variants in the Portuguese language in Portugal, there are no ISO codes to identify possible variants. Anyway, it’s something we have to address and we wanted the Polyglots to help us.

    Does anyone have any idea how we can deal with this?

    Thanks.

     
    • TacoVerdo 1:48 pm on May 20, 2015 Permalink | Log in to Reply

      It sounds like this is quite like the situation the Germans have with default vs formal language. They have two projects on translate.wordpress.org.

      Could that be a solution for you as well?

    • Alvaro Gois dos Santos 2:42 pm on May 20, 2015 Permalink | Log in to Reply

      Hi Taco,

      Thanks for replying.

      As a matter of fact, we already have two similar projects on translate.wordpress.org, for formal (default) and informal Portuguese.

      But this isn’t enough, since it’s only an infrastructure for collab translation management, not actually a way for everyone to add the alternative version to WordPress.

      Unless there’s an easy way to get those alternatve language files from the repository. Is there?

      I came across a plugin (WPTB) to change WordPress language from within the admin, but, as WordPress core itself already does, it only loads the default language packs. In a situation were we have no variants, no ISO codes that identify the alternative language files, we cannot load the pack from the repo.

    • Torsten Landsiedel 10:40 am on May 21, 2015 Permalink | Log in to Reply

      Here is the trac ticket for that:
      https://core.trac.wordpress.org/ticket/28303

      The whole German community is hoping for a solution!

      @ocean90: You said, we have to think about a core solution. Is someone working on that already? Can we help?

      • Alvaro Gois dos Santos 10:45 am on May 21, 2015 Permalink | Log in to Reply

        Do you have any experience with a solution that overrides the default packages, but using the same locale with packages on an alternative repo?

        We’ll probably try a solution like that for the Portuguese Orthographic Agreement version. It’s not perfect but can be accessible, if it works…

    • Angelika Reisiger 7:12 pm on May 21, 2015 Permalink | Log in to Reply

      This is a huge problem for a lot of countries. After a short research I found this wikipedia article:
      https://de.wikipedia.org/wiki/H%C3%B6flichkeitsform#Die_H.C3.B6flichkeitsform_in_anderen_Sprachen

      They don’t list all countries with formal and informal language, but here are a few:
      France, Finland, Germany, Portugal, Hungary, Luxembourg, Serbian, Montenegro, Bosnia, Herzegovina, Croatia, Russia, Nederlands, Poland, Japan, China

      You could also read:
      https://en.wikipedia.org/wiki/Honorific

      All these countries only can use an informal (and rude) address to the visitors of their WordPress Website. Even, if they install the formal language – after the next wp-update will override the informal language.

      Please, take this problem seriously, cause it is a serious problem for all the WordPress Admins in such countries. Can we help?

    • Alvaro Gois dos Santos 9:04 pm on May 21, 2015 Permalink | Log in to Reply

      As to the formal vs. informal, that’s also a problem for us in Portugal, as you mention, though we have the opposite situation, our default language is formal and we have an informal GlotPress branch which is not accessible for the average user.

      What we’re trying to achieve, using a plugin, is a way to override the default language files for new ones, managed by the Portuguese Community. Possibly in an alternative GlotPress or Github repo.

      Why? Because there’re no variants in the Portuguese language (Portugal), hence we’ve to use the same ISO code so that other translations don’t break.

      I’ll post our findings here, Angelika.

    • Alvaro Gois dos Santos 10:41 am on May 25, 2015 Permalink | Log in to Reply

      @tacoverdo, @zodiac1978, @la-geek: update on language variants. We’re now testing a plugin solution that will enable local communities to ship language variants with their version of the plugin. So far it seems the best way to have a community driven solution that takes advantage of already existing translations, without imposing any variant.

      As to the specifity of Portuguese language translations, our goal is to avoid dispersing translation resources.

      I’ll be updating this soon 😉

      • Torsten Landsiedel 10:53 am on May 25, 2015 Permalink | Log in to Reply

        I would really prefer a core solution (as @nacin promised me @ WordCamp Europe in Sofia one year ago 😉 – but a community driven plugin workaround would be great until this is fixed. Please keep us updated! If we can help / beta-test, please ping me/us as well!

        • Alvaro Gois dos Santos 10:58 am on May 25, 2015 Permalink | Log in to Reply

          Thanks! I would have to agree with you as to a core solution, truth is we have an immediate demand.

          And a core solution won’t be that easy, I suppose, due to the ISO codes regarding locales and the possibility of disrupting plugin and theme translations.

        • Andrew Nacin 2:13 am on May 27, 2015 Permalink | Log in to Reply

          It’ll happen! I know @ocean90 has been looking into it, and I have some ideas. There’s some movement happening now on user locales (https://core.trac.wordpress.org/ticket/29783) and I suspect these will both move forward together in some way.

          It isn’t too hard to do, we just have to change how we key things and introduce a slight tweak to how we store locales in the DB and on the filesystem. So something like pt_PT_informal. Not a hard problem and won’t disrupt anything. Just takes time.

    • Angelika Reisiger 3:55 pm on May 26, 2015 Permalink | Log in to Reply

      Thanks @alvarogois for the heads up! Yeah, a core solution would be the best one – of course. But your efforts to build a plugin are really great and very appreciated. Do you need any help with testing in other language – here german formal?

      • Alvaro Gois dos Santos 4:17 pm on May 26, 2015 Permalink | Log in to Reply

        Hi @la-geek. We already have a plugin in test mode :)

        We’re facing some issues with server memory.

        I believe we’ll have a version for beta testing soon.

        It’s not the perfect solution but can be a temporary one.

        In it’s current form, the plugin installs two variants of the Portuguese (pt_PT) language, namely, Portuguese Orthographic Agreement (1990) and Portuguese Informal. After plugin installation, user goes to options > general and has two more options below the site language, one for frontend and the other for backend. It’ll only work if the exact same locale is defined, in this case Portuguese (Portugal), because the plugin overrides the locale’s default, admin and network admin language files. My guess is that this is the only way plugins’ and themes’ translations won’t break.

        To make it work with other languages – if we maintain the current architecture –, it has to be edited to work with your locale.

        I thought of a larger scale infrastructure, one where you could have a group of WordPress language variants. But I sense a lot of issues.

        In Portugal we have a small community, relatively close to one another. We almost know everyone who’s involved translating WordPress. But in other countries is not like that. It would be impossible to validate the accuracy of variants in an 100% open environment. I’m not sure how to do it.

        As soon as we get to beta I’ll post it here for everyone who wants to give it a try (and help making it better 😉 ) .

    • Alvaro Gois dos Santos 12:38 pm on May 28, 2015 Permalink | Log in to Reply

      Update: we now have a working plugin we called PT Variants available from WordPress.org (way faster than we thought…) and GitHub.

      It installs two variants of the Portuguese (pt_PT) language, namely, Portuguese Orthographic Agreement (1990) and Portuguese Informal. After plugin installation, user goes to options > general and has two more options below the site language, one for frontend and the other for backend. It’ll only work if the exact same locale is defined, in this case Portuguese (Portugal), because the plugin overrides the locale’s default, admin and network admin language files.

      To make it work with other languages it has to be edited to work with your locale.

    • Angelika Reisiger 4:27 pm on May 31, 2015 Permalink | Log in to Reply

      I had subscribed here for follow-ups, but did not receive any email :(.

      Does this plugin fetch the language files from https://translate.wordpress.org/languages/… ?
      I am not sure, but I don’t find this in pt-variants.php, so I guess, the files shall be uploaded manually?

      • Alvaro Gois dos Santos 8:47 am on June 1, 2015 Permalink | Log in to Reply

        Hi @la-geek. In fact, we’ve considered the possibility even of having a custom repo for language variants, one that could be used for various countries. But I believe it could be a problem to manage several different and concurrent versions for the same locales.

        We also had the matter of urgency. Therefore, we decided to include the existing variants. It allows us to validate the files.

        That doesn’t mean we’re not interested in a more general approach. Any ideas on that?

        What do you think of the plugin as it is now, have you tested it yet?

    • Angelika Reisiger 5:19 pm on June 1, 2015 Permalink | Log in to Reply

      Hi Alvaro, it is not so trivial to test this plugin. There are no “ready to go” german informal language files. They must be exported (from polyglot) and renamed. Second the plugin must be forked and edited for the german purposes.

      I will try this, but I don’t know, how successful I will be :). Could you please confirm, that the test procedure is as follows:

      Upload the language files, Install the plugin, change your preferred language variant (formal or informal)
      and then – how to trigger the process, that overrides/updates the language files normally? Could this be achieved with the installation of an older plugin or theme and after I click on update in WP Back end, the overriding process of language files starts?

      So I can test, if your plugin works and prevent the override of language files?

      • Alvaro Gois dos Santos 5:32 pm on June 1, 2015 Permalink | Log in to Reply

        Hi Angelika. The default language files are just override, their aren’t deleted.

        You’ll have to compile the variant you want to test. Make sure you have the same locale extension to your WordPress default install as this is essential.

        You’ll have to fork the plugin and edit the pt-variants.php so that it recognizes your exact variant (lines 35, 78 and 79).

        I’ll ask Marco Pereirinha to make this process more clear here. He’s the actually code-ninja.

    • Angelika Reisiger 5:40 pm on June 1, 2015 Permalink | Log in to Reply

      Hi Alvero,

      how I can test, if the plugin works? I must start a procedure to test it <- this is my question, how to start this.

      Next question, after I looked into the plugin:
      you have two different language files:
      pt_PT-AO
      pt_PT-INF

      Are these new names? So that means, I have to rename and upload both language files (formal and informal)?

      From de_DE (what is the normal name for german language file) to

      de_DE-FO (for formal variant)

      and rename the informal language file to
      de_DE-INF (informal variant)

      Of course I have to edit the pt-variants.php on lines 79 and 80, so that it will work.

    • Alvaro Gois dos Santos 5:43 pm on June 1, 2015 Permalink | Log in to Reply

      You’ll only need one file, we’ve introduced 2 variants because we have Orthographical Agreement version and Informal version. Our WordPress default pt_PT is Formal.

      So, I’d go with de_DE-FO and change the file references in the pt-variants.php file, as I mentioned above.

      • Angelika Reisiger 5:46 pm on June 1, 2015 Permalink | Log in to Reply

        So you have three variants in portugese language? formal, informal and OA? One of them ist default?

        How to test, if this plugin works and if it is prevented before overridings?

        • Alvaro Gois dos Santos 5:54 pm on June 1, 2015 Permalink | Log in to Reply

          Ja, default with WordPress pt_PT install is Formal.

          pt_PT-AO is Orthographic Agreement variant
          pt_PT-INF is Informal version

          If you fork the plugin and edit the lines mentioned above, and include your own version of de_DE-FO, you should see the difference. I’m guessing you already have those formal files for your own installs, don’t you?

          • Angelika Reisiger 5:58 pm on June 1, 2015 Permalink | Log in to Reply

            Oh, therefore I was confused. I thought, with this plugin you can switch between informal and formal language :)

            But now I see, that the plugin works (and is only needed), if you want to use another variant of language – instead of the default language. No need to switch.

            Okay, so far so good :)

            • Alvaro Gois dos Santos 6:02 pm on June 1, 2015 Permalink

              Yes, it just overrides the default language files with a custom variant, using the same locale.

              So, you only need it if you want to use a variant to the default language in your install.

              We’ve done it so that anyone could activate a pt_PT-AO variant without having to go through FTP and copy over the original files.

        • Alvaro Gois dos Santos 5:56 pm on June 1, 2015 Permalink | Log in to Reply

          If you only want to test the concept, you could even just change pt_PT for de_DE. You would have your dashboard in Portuguese!

          • Angelika Reisiger 6:03 pm on June 1, 2015 Permalink | Log in to Reply

            In the actual version it is only useful for portugese language. There are no options, to use it in other languages. What are your future plans?

            Will you develop the plugin to fit the needs of other languages and extend the line 76, the array and upload all the other language files?

            I don’t think so :). So, how can we (german atm) benefit of this plugin? The only way – I see – is to fork it and change all strings, that are needed for german purposes.

            Or will there be another way to globalize this plugin?

            • Alvaro Gois dos Santos 6:26 pm on June 1, 2015 Permalink

              We had a two issues: urgency and proof of concept.

              The way I see it, to globalize it, it should load variants for other languages or be packed for specific languages.

              As I mentioned earlier, I thought of a larger scale infrastructure, one where you could have a group of WordPress language variants. But I sense a lot of issues.

              In Portugal we have a small community, relatively close to one another. We almost know everyone who’s involved translating WordPress. But I can’t say the same for other countries. It would be impossible to validate the accuracy of variants in an 100% open environment. I’m not sure how to do it.

              What are your ideas on this?

    • Angelika Reisiger 6:33 pm on June 1, 2015 Permalink | Log in to Reply

      The official translated files are all hosted and maintained on translate.wordpress.org (also the other variants of languages – at least in german case). There are validators (like you) who proof the language strings. What are your concerns?

      The problem I see is the mainenance of these language files. It would be perfect, if the plugin would fetch the files from translate.wordpress.org. But they must be renamed, that the next issue. I don’t know :(

      • Alvaro Gois dos Santos 6:55 pm on June 1, 2015 Permalink | Log in to Reply

        OK, if it could read from the translate.wordpress.org repo there would be no problem, except for the files’ names.

        I could even agree with a plugin where you would only have access to variants for the locale actually loaded by WordPress. So, one could choose the locale (default language), like pt_PT or de_DE, and, after that, an option to load variants from the repo.

        That would be the the best UX, I guess. But it implicates a change on both translate.wordpress.org and WordPress itself. Maybe in the way @nacin points out up there.

    • Alvaro Gois dos Santos 11:19 am on July 15, 2015 Permalink | Log in to Reply

      I’m flagging this “resolved” as variants are getting into core.

  • Drew Jaynes 1:11 pm on April 3, 2015 Permalink |
    DrewAPicture
    Tags: ,   

    “Soft” string freeze

    This morning we released 4.2 Beta 4, and as promised, we’ve also reached soft string freeze.

    “Soft” string freeze constitutes a freeze on all new strings, excluding the About page. You can expect a “hard” freeze once we tag RC1 in a week or so, and that will include the About page strings.

    It’s likely you’ll be seeing some changes to existing strings trickling in over the next few days as @nacin goes through and audits changes from the release. We’ll do our best to keep that to a minimum.

    According to the 4.2 release schedule, we’re right on track for an April 22nd release.

     
  • Andrew Nacin 8:50 pm on February 24, 2015 Permalink |
    nacin
    Tags:   

    Thought it might be fitting to post this as today marks five years since @ocean90‘s first patch to WordPress. As has been obvious to some of you, I have stepped back from i18n in the past few months, especially after 4.1’s release and as WordCamp Europe, WordCamp SF, the community summit, and Slack have empowered so many of you. I am stretched across a lot of projects, and Dominik very willingly stepped up to take on a lot of responsibility for improving Rosetta, core language packs, and related projects. He’s a highly respected WP core developer, he’s previously helped me on a number of i18n projects, and he’s slid into this role with ease. It’s also time for the technical point of contact to be a polyglot again. :-)

    @stephdau has also been instrumental for the massive project to translate plugins and themes (including language packs, localized plugin/theme directories, and the like). Also, you may have noticed a lot of coordination across these initiatives now happens in a #meta-i18n channel on Slack.

    While I haven’t gone anywhere and I’m still helping a bit behind the scenes, please consider @ocean90 the new @nacin and the primary point of contact core/dotorg i18n and the like!

     
  • Kazama 6:27 am on January 29, 2015 Permalink |
    kazama • th.wordpress.org editor  

    It seem to me that the complete status of this page are wrong.
    https://translate.wordpress.org/projects/wp/dev/admin
    Anyone can confirm or just me to see this error. It shows 100% completed in some languages but when you look inside there are many strings (10 page at least) that aren’t translated.

     
  • pavelevap 1:10 pm on January 16, 2015 Permalink |
    pavelevap • cs.wordpress.org editor  

    This string is not available in GlotPress: https://core.trac.wordpress.org/browser/tags/4.1/src/wp-admin/includes/schema.php#L361

    It should be in Administration project, but it is missing.

    All localized versions are missing this string and that is why there is default zero offset.

    Maybe @nacin should look at it?

     
  • Andrew Nacin 12:25 pm on December 18, 2014 Permalink |
    nacin
    Tags: , ,   

    WordPress 4.1 instruction manual

    Hello polyglots! In the next 3 hours or so, @johnbillion will be starting the release process (in #core in Slack). Please make sure you are 100% translated for WordPress 4.1 and all subprojects, and also do not forget about the Akismet project.

    I’d expect a release somewhere around 1600 UTC, but for most locales, the release process is now automated. Please read on.

    Part 1, Language Packs

    If you are 100% translated at the time of 4.1’s release, a language pack will be generated for you. This is a ZIP file consisting of PO and MO files only, and is used for the language chooser during the install process, and for the language switcher on the settings screen.

    If you become 100% translated some time after 4.1’s release, a language pack will be generated for you once the script is run. This will be around every hour.

    If you are 100% translated, a language pack has been created, and then you modify a translation to fix a typo or whatever, a language pack will be regenerated for you once the script is run. Please do not do this with unnecessary frequency, as it triggers an update across all WordPress sites.

    Part 2, Release Packages — IMPORTANT CHANGES AHEAD

    release package is what you’re used to building using the form on Rosetta’s dashboard. This is a ZIP file consisting of WordPress in its entirety, along with PO and MO files for core, the PO and MO files of default themes and Akismet, and any custom changes you have.

    Do you have custom changes? For the purposes of this exercise, your locale falls under one of these four groups:

    • You have never had any custom changes and i18n.svn.wordpress.org is entirely empty for your locale.
    • You have no custom changes for 4.1.
    • You have minor custom changes consisting of, at most, a translated readme, license file, and wp-config-sample.php.
    • You have extensive custom changes consisting of other files, such as wp-content/languages/$locale.php or core modifications.

    Here are the details on each:

    • If you have never had any custom changes and i18n.svn.wordpress.org is entirely empty for your locale, you do not need to do anything. Your release package will be created automatically for you. An example locale is en_GB.
    • If you have no custom changes for 4.1, please ensure you have an empty branches/4.1/dist or tags/4.1/dist directory at i18n.svn.wordpress.org. (Having an empty trunk/dist directory does not help you.) You do not need a dist directory if branches/4.1 or tags/4.1 is empty. An example would be nl_NLYour release package will be created automatically for you.
    • If you have minor custom changes consisting of, at most, a translated readme, license file, and wp-config-sample.php, please ensure these files exist in a branches/4.1/dist or tags/4.1/dist directory at i18n.svn.wordpress.org. (Having your stuff in only trunk/dist does not count.) An example would be eo or fr_FRYour release package will be created automatically for you.
    • If you have extensive custom changes consisting of other files, such as wp-content/languages/$locale.php or core modifications, you will need to create a package via Rosetta as you have done in the past. For this, We are phasing out the ability to ship any customizations beyond license, readme, and wp-sample-config.php. This means you need to reach out to the WordPress core contributors to fold your modifications into WordPress core. You can start this process by creating a Trac ticket.

    To summarize:

    • If all you have is a license, readme, and wp-config-sample.php (or no custom changes at all), everything will be automated for you for WordPress 4.1 if you follow the instructions above. Both language packs and release packages will automatically be created once 4.1 is announced. If you are not at 100% at that time, then language packs and release packages will be created when you reach 100%. If you are later modify a translation (to fix a typo, for example), your language pack and release package will be regenerated.
    • If you have extensive custom changes, you will need to manually create a package via Rosetta as you have done in the past. This option is being phased out in 2015.

     

    If you go to the releases screen on your Rosetta dashboard, you’ll see a new notice that explains what the system thinks your status is. If you have any questions, comments, concerns, or issues, please comment here or find me or @ocean90 in #polyglots on Slack.

    If your locale is currently eligible for automatic creation of release packages (which includes being at 100%), you’ll find an RC3 build generated from tags/4.1-RC3 waiting for you on your dashboard. Please inspect these ZIPs. Those locales are: az, bs_BA, de_DE, en_CA, en_GB, eo, fi, fr_FR, it_IT, nb_NO, nl_NL, pt_PT, ro_RO, and sv_SE (zip links).

     
  • Petya Raykovska 12:15 pm on December 18, 2014 Permalink |
    petya • bg.wordpress.org editor
    Tags: , WordPress 4.1   

    Dear polyglots,

    WordPress 4.1 will be released in a few hours.

    I wanted to give you the current status on updated locales and ask some of you for some last efforts so we can have more locales at 100% before the release. Currently we have 66 locales that are above 90% for WordPress, 56 above 90% for Admin and 54 above 90% for the Network Admin.

    The projects and subprojects mentioned below are required for a release in order for a locale to get a language pack and automatically get in the language chooser.

    WordPress is at 100% for 33 locales

    SlovakWelshAlbanianDanish and Rohingya are at 99%

    IcelandicLithuanian and Serbian are at 98%

     

    WordPress Administration is at 100% for 33 locales

    SlovakWelshAlbanian and Serbian are at 98%

    BurmesePersianDanish and Chinese (Taiwan) are at 97%

     

    Network Administration is at 100% for 52 locales

    as there haven’t been any new strings there for this release,

     

    Twenty Fifteen is at 100% for 31 locales

    SlovakCzechKoreanWelshAlbanian and Serbian have between 1 and 3 strings to get to 100%

     

    Akismet is at 100% for 35 locales

    Spanish (Peru), French (France), Scottish GaelicAlbanianSpanish (Chile)Chinese (China)Chinese (Taiwan)Slovak and Spanish (Spain) all have just one remaining string.
    It would be great if the validators for the locales mentioned above could step up and translate those last couple of strings that are remaining.

     

    I’m pinging the most active of you, based on the w.org activity.

    Thank you in advance for your work. @nacin will post extended instructions for the 4.1 release for all of us today.

    Cheers!

    Petya

     
  • Peter Holme Obrestad 11:52 am on December 17, 2014 Permalink |
    peterhol • no.wordpress.org editor
    Tags:   

    I have given out our language url (https://translate.wordpress.org/languages/nb) to potential translators. I recently discovered that the “Administration” partial of the WordPress translation isn’t visible there. This led to me not getting any help with that one this time… What’s up with that? 😉

     
  • Krzysztof Trynkiewicz (Sukces Strony) 8:54 pm on December 15, 2014 Permalink |
    eclare • pl.wordpress.org validator  

    @nacin We still have a few strings that aren’t translatable.

    https://core.trac.wordpress.org/browser/trunk/src/wp-admin/about.php#L94
    https://core.trac.wordpress.org/browser/trunk/src/wp-admin/about.php#L99
    https://core.trac.wordpress.org/browser/trunk/src/wp-admin/about.php#L103
    https://core.trac.wordpress.org/browser/trunk/src/wp-admin/about.php#L124

    What about them for 4.1?

     
  • Petya Raykovska 2:51 pm on December 8, 2014 Permalink |
    petya • bg.wordpress.org editor
    Tags: , ,   

    Polyglots chats Summary Dec 3rd and Dec 4th… 

    Polyglots chats Summary: Dec 3rd and Dec 4th

    ArchiveAgenda

    We’re going to try to adopt the structure of core’s chats summaries. Here goes.

    Hits:

    • Tagalog has a new translator team thanks to a call for new translator on slack worked well. @krzheiyah, @kel and @druesome joined the effort
    • 41 locales are up to date
    • We have some of the new strings in GlotPress ready to translate.

    Misses:

    • We still don’t have a 4.x Project on GlotPress
    • No string freeze yet and no information on when it or RC1 is happening (it’s obviously late)
    • 15 locales still behind on 4.0.1. (at the time of the meeting they were 16). @netweb has created a list of locales that are packaged still with 4.0

    ToDos:

    • Research how different teams approach communication of translations and create a recommended process for new teams (@petya will work with @vanillalounge and @coachbirgit and post on the P2)
    • Work with core to create the 4.x project on GlotPress (that’s on @ocean90 and @nacin)
    •  Think about a way to alert validators and translators that there are new strings to translate and help them with packaging (Thanks to @netweb for raising the question)
    • @petya will add instructions on creating and importing/exporting Glossaries to the Handbook (Thanks to @deconf for pointing out we actually can)

    Open discussion topics:

    • GlotPress improvements: suggest translation button, communication tools for validators and translators, Glossary
    • Language style guide and how to build them
    • Communication channels for translators and validators and different approaches to discussing translations
    • How we can help a locale that lacks translators/validators: we ask the current validators if they have anyone, then try everything we can
    Next Polyglots chats: Wed, 10th Dec, 11:00 UTC and Thu, 11st Dec, 02:00 UTC
     
    • Emre Erkan 3:15 pm on December 8, 2014 Permalink | Log in to Reply

      FYI tr_TR is no longer at 4.0, it’s at 4.0.1 :)

    • Stephen Edgar 11:39 pm on December 9, 2014 Permalink | Log in to Reply

      We have 43 locales now up to date with 4.0.1 :)

      How are we looking for 4.1? Without clicking through each project and sub project (/admin, /network, /akismet et cetera) it’s difficult to get an overview… It would be great if we could extend some type of summary at https://translate.wordpress.org/languages.

      Kind of related and raised in #gotpress on Slack was this from @joostdevalk:

      https://wordpress.slack.com/archives/glotpress/p1417790668000540
      “…overall stats per locale to GlotPress”

      My thinking here is rather than “overall stats per locale” we add a summary of percentage completed for the current release and the next release. For 4.1.x this would include stats from /dev, /admin, /network, /akismet, /twentythirteen, /twentyfourteen, /twentyfifteen yet for 4.0.x the stats would not include /twentyfifteen as that wasn’t an included project for the 4.0.x release if y’all get my drift.

      • Petya 9:20 am on December 10, 2014 Permalink | Log in to Reply

        I use http://wpcentral.io/internationalization/, Marko recently added percentage for core, makes it easy.

        For the rest, if need be, I do by scanning locales one by one. Can’t really afford doing proper stats for everything now, would mean way too much time.

        It would be great to have that here https://translate.wordpress.org/languages along with all the other info that’s currently at wpcentral.io and the percentage for each project that’s required for a locale to get as an option in the initial WP install.

  • Petya Raykovska 7:17 pm on November 18, 2014 Permalink |
    petya • bg.wordpress.org editor
    Tags: , ,   

    Agenda for the Polyglots chats Nov 19th &amp; 20th 

    Agenda for the Polyglots chats Nov 19th & 20th

    Hello dear polyglots,

    Almost time for the scheduled Wednesday and Thursday Polyglots chats. Here’s the proposed agenda:

    1. Update on existing l10n
      • 53 locales up to date
      • 6 locales down by one major version
      • 15 locales down by two major version or more
    2. How can we get more localizations active?
      • Contacting validators from the locales down-by-one (mk, nn, es-mx, tl, ta-lk, vi) and offering support
      • Maybe contact other validators and see if they’re in progress or inactive
      • If a locale is inactive, we need to find new validators
      • @Petya will contact the following locales: de-ch, ka, bel, lv, af
      • Who else wants to help contact locales?
    3. WordPress 4.1
      • Coming soon. About three weeks away.
      • String freeze is at RC, but when is RC? Schedule in flux.
      • Let’s get this on the agenda of the core team. @johnbillion @nacin
    4. Technical Chat
      • We need to schedule a “technical” chat to go over the technical responsibilities of the polyglots team.
      • Role includes things like Rosetta, deploy requests, and dealing with make/polyglots requests.
      • Let’s try for Monday or Tuesday. Who’s interested and when can you attend?
    5. GlotPress redesign status
      • Do we know what the current status of the UI changes for GlotPress is? Would be great if @teamadesign could join one of the chats and let us know.
    6. Open Discussion

    If you have any suggestions for the agenda, please add them in the comments below.

    Cheers!

    Petya

     
    • Marko Heijnen 7:24 pm on November 18, 2014 Permalink | Log in to Reply

      To have less chaos I rather would like to no discuss GlotPress during the Polyglots chat. Specially if that would involve a complete redesign.

      • Petya 7:30 pm on November 18, 2014 Permalink | Log in to Reply

        How is reporting on progress causing chaos? :)

        • Marko Heijnen 7:31 pm on November 18, 2014 Permalink | Log in to Reply

          Because that reporting should be done on http://blog.glotpress.org and not here.

          • Catiakitahara 1:56 am on November 19, 2014 Permalink | Log in to Reply

            Hey @markoheijnen (what’s your handle?), I was the one who suggested it to @petya. I agree with you GlotPress should be discussed at its own blog, however I don’t agree we can’t have a brief report in our channel. I think it’s reasonable to share this information with us, mainly because it’s not anywhere yet. We don’t need to go into details and as you’ll be there, I guess, you can interfere and politely ask us to change rooms if you think we’re starting to promote chaos. In other words it doesn’t hurt anyone to come to our meeting, make a brief report and use that chance to invite people who are interested to discuss the matter at the appropriate channel. 😉

            • Marko Heijnen 9:00 am on November 19, 2014 Permalink

              It’s in the end my call to make and I would like that if I make a decision to GlotPress that people would respect that. If there wasn’t anything discussed on GlotPress then there is nothing to report on Polyglots.

              It would be weird if teamadesign also needs to show up if someone else with a GlotPress installation would want to know the current redesign status like if another CMS would use it.

    • Daisuke Takahashi 11:26 pm on November 18, 2014 Permalink | Log in to Reply

      I’d like to hear the current status of Plugin&Theme Directory internationalisation and team P2.
      (e.g. https://de.wordpress.org/team/, https://ja.wordpress.org/plugins/)
      And translation schedule of them.

    • Sergey Biryukov 5:07 am on November 19, 2014 Permalink | Log in to Reply

      I’m interested in the “technical” chat. Monday or Tuesday works for me, any time from 10:00 to 22:00 (UTC).

  • Sithu Thwin 11:00 am on November 18, 2014 Permalink |
    herzcthu • mya.wordpress.org editor
    Tags: , ,   

    I’ve opened a ticket #29664 two month ago. No one response. Today I’ve attached a patch file to support Myanmar script font-family.
    I’m looking for a way to embed google web font for Myanmar.
    I want to know if it is possible to embed in WP core or do I need to release Locale specific Package with embedded fonts.
    Is there a way to add Word Break rules js file in WP core?

     
  • Stefano Aglietti 8:38 am on November 15, 2014 Permalink |
    SteveAgl • it.wordpress.org editor
    Tags: , twentififteen   

    WordPress 4.1 is on Beta stage would be nice to have finally the 4.X branch and having the ne twentyfeifteen theme too, even if there will be changes in strings we could start to translate and not having to rush in the last 2 days before release.

     
  • Stephen Edgar 10:30 pm on November 5, 2014 Permalink |
    netweb • en-au.wordpress.org editor  

    iOS 4.5 translations has funky negative counts for ~12 locales untranslated strings

    https://translate.wordpress.org/projects/ios/45

    Ping @nacin, can you do that DB thing you love to do 😉

     
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