WordPress Polyglots

Updates from Andrew Nacin Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 9:16 pm on April 5, 2012 Permalink | Reply
    nacin
    Tags:   

    I added persistent caching to translate.wordpress.org, fixed a bug in GlotPress, and tweaked a few things. The result: GlotPress is now super fast. Even the really slow project pages now load in an instant. See for yourself: http://translate.wordpress.org/projects/wp/dev. Let me know if you see anything funky, such as stuck values (caching issues) etc.

     

    • Zé 9:28 pm on April 5, 2012 Permalink | Reply

      8O

    • Mattias Tengblad 10:41 pm on April 5, 2012 Permalink | Reply

      Nice! Good work :)

    • Carlos E. G. Barbosa 12:22 am on April 6, 2012 Permalink | Reply

      Great! Thank you!

    • Wacław J. 10:53 am on April 6, 2012 Permalink | Reply

      What does persistent caching mean?

      • Andrew Nacin 12:50 pm on April 6, 2012 Permalink | Reply

        In this case, it means that we’re now caching data in memcached, a persistent data store. So we query something expensive on one pageload, store it in cache, and pull it from memcached (rather than the database) until that cache gets cleared. Going to memcached is often going to be quicker than the DB, especially for expensive (or high numbers of) queries. A particular cache then gets cleared when the data changes (a count of translated strings gets reset when a string is translated, etc). All you really need to know, though, is that it is awesome. :-)

  • Andrew Nacin 5:02 pm on April 4, 2012 Permalink | Reply
    nacin
    Tags: , ,   

    I think we are going to turn off the SVN builder for 3.4.

    You will still be able to use your SVN directory, and we will continue to pull files from /dist (like readme.html and wp-config-sample.php). But, in order to create a build, you will need to import any po/mo files you have into the wp/dev projects at translate.wordpress.org.

    GlotPress is all about collaboration. So others may help, it is preferred that you periodically import your po/mo files there (if you work with a separate tool), rather than importing them at the end in order to do a release. This also isn’t just about collaboration. At some point, I’d like to make it so you can mark your locale as “ready” for a release. Then we will simply create the build for you when we release WordPress.

     

    • Gabriel Reguly 5:29 pm on April 4, 2012 Permalink | Reply

      Hi Nacin,

      That is great news.

      But please test the GlotPress build option thoroughly before disabling the option do use the SVN builder.

      See, it was not working well for both 3.3 and 3.3.1, so I had to make the pt_BR build using the SVN option.

    • Xavier 10:44 pm on April 4, 2012 Permalink | Reply

      Can’t say I’m too thrilled about this move. But while I don’t see how it it necessary to make us use GlotPress as the One Tool (import questions aside), I can’t say I wasn’t seeing this coming sooner or later.

      • Andrew Nacin 11:18 pm on April 4, 2012 Permalink | Reply

        It is necessary because:

        There are many things we have in mind that make more sense if they were centralized in a single web-based tool (and that’s coming from someone who loves Subversion and uses it every day).

        For example, files like wp-config-sample.php and readme.html could become managed through an screen in Rosetta, rather than via Subversion. Ideally, you should not need SVN at all to manage a translation — that’s the end goal here. Also, we are now sending a number of strings into POT files that aren’t actually strings, like timezones, character vs word counting, and more. I would like to make those appear differently in GlotPress. I am already monitoring these values with simple database queries, and with GlotPress, we can even do things like special validation and views.

        When we begin to expand to crowdsourcing the translation of plugins and themes, we’re going to continue to expand our use of GlotPress. SVN will not be involved. It can’t scale in the technical sense and more importantly when it comes to learning curves and barriers to entry. We should all be using the same product and be on the same page. (As you said, it was going to happen sooner or later.)

        Another thing is to consider security and validation, to help ensure that bad or broken things don’t get into strings. If it goes through GlotPress, we can evaluate everything on a string-by-string basis and it all sits nicely in a database. If it goes through Subversion, we cannot. This is very important especially as we begin to open up translate.wordpress.org to plugins and themes.

        And so I ask, why aren’t you thrilled about this move? I understand this will change your workflow in particular (even if all you need to do is import a few PO files, which will take 2 minutes). So I would appreciate some specifics, as maybe I can help.

        • Xavier 9:53 pm on April 9, 2012 Permalink | Reply

          Oh, no worries, I hear your points loud and clear, as I do Zé’s, and completely understand that comes a time when you need to focus your energy on the most manageable and accessible tool, which SVN clearly is not for newcomers.

          As you said, this is more a question of workflow: I for one like to use Poedit (and even donated to the project :) ), and the GP interface just doesn’t do it for me. As such, I’d hate to see SVN support go the way of the dodo, but again, I’m sure this time will come.

          So, while I’m an old man who sees his world start to crumble, I do sincerely welcome the forward-looking thinking behind this decision, and support it. I also am glad to see you Andrew taking care of our ageing community. Go youngsters! :)

      • Zé 12:06 am on April 5, 2012 Permalink | Reply

        You also have to keep in mind that the profile of people willing to donate their time to translating WordPress isn’t necessarily one that has a working knowledge of SVN. Granted, many of us do, but the reason for that is both historical and fading away, i.e. in the beginning the ones translating were very often developers who needed a localized version, and even if they did not know SVN, they were familiar with the mindset required to learn it. As the number of languages and audience of WordPress grows, so is said profile shifting more towards those interested in the language itself and less in the underlying technology.

      • Mattias Tengblad 1:04 am on April 5, 2012 Permalink | Reply

        I’m with Xavier here.

        But taking Nacins post into account, I do agree with his points, just don’t think we’re there yet.

        Has there been one release where GP has not been screwing things up? Since I follow all the discussions here I’ve seen all the questions/problems with GP on release day and there for I have never used it as a source when building packages (never been any problems using SVN).

        I really want to see a well worked trough GlotPress software and an integration with the locale sites before this is happening. I don’t see GlotPress as a stable enough software yet.

        • Andrew Nacin 1:23 am on April 5, 2012 Permalink | Reply

          GlotPress does not handle release packaging. Rosetta does. And it is the same codebase, and largely the same code, that handles builds from both GlotPress and SVN. As you agree with my points, you understand why it makes sense for us to choose GP as the One Tool (as Xavier put it).

          I’ve seen just as many questions on release day about SVN. Please point me to a GlotPress or Rosetta problem that is unresolved and I will fix it. (I’m serious.)

          You guys finally have a developer who is invested on a nearly daily basis to ensure that GlotPress and Rosetta not only work, but work consistently. (That’s me, howdy!) They’re not going anywhere, so pull up a chair — we’re going for a ride. :-)

          • Mattias Tengblad 1:36 am on April 5, 2012 Permalink | Reply

            Just tried to build a package with the new changes http://wppolyglots.wordpress.com/important-changes-for-wordpress-3-4/ not working…

            Standardnyckeln i dist/wp-config-sample.php matchar inte $wp_default_secret_key i sv_SE.php. Nyckeln i sample config är:

            och den angiven i sv_SE.php är:

          • Mattias Tengblad 1:56 am on April 5, 2012 Permalink | Reply

            What I meant was that if you where using the translations from GP it screwed things up. In other words the relation, GP Rosetta ;) If those bugs are all fixed, then nice :)

            Things that needs fixing in GP:

            Loading a GP page takes ages.
            Fuzzy strings, not working at all in GP.
            Changes between versions needs to get automated, especially since importing seems to bug from time to time. Exporting -> importing between versions isn’t user friendly.

            (Maybe a bit OT, I would love to see GP as a plugin, kind of like bbPress)

            • Andrew Nacin 2:06 am on April 5, 2012 Permalink

              Loading particular pages take ages. It has been on my list to take a look. However, the slowest pages are ones that give a heads-up display of all translation sets, rather than a page that a single translator reasonably needs to be fast.

              Nothing prevents you from using your tool of choice to take advantage of fuzzy strings before GlotPress supports them. It’s just that instead of committing your PO file when you are done, you import it into GP.

              I am not aware of importing bugs. If you have an issue with importing, send me the PO file and I will test.

              I agree, changes between versions is totally lame. I am going to try to write a CLI tool that I can use to migrate all translation sets.

              GP was written as a standalone app, and it makes sense to remain that way. There really isn’t any reason to re-architect it, except to overcomplicate it and use up valuable developer time.

            • Andrew Nacin 9:16 pm on April 5, 2012 Permalink

      • Cátia Kitahara 7:10 pm on June 20, 2012 Permalink | Reply

        Lately I haven’t helped the Brazilian translation team and Gabriel has been the responsible for the releases, so I’m sorry if I’m saying something stupid. I’m back to it now, I helped translate the last release. But what I feel, is that our translation lost quality because we don’t proof read anymore. I used to do this job with a friend every new release, and we did that with poedit. We split the strings between us, like I did strings 1 to xxx and him from xxx to the end. With GlotPress this process isn’t possible. We tried to split the pages by their numbers, but then some people without admin permission sent their suggestions and them the page numbers were augmented so we didn’t know anymore which ones were lacking proof read. I don’t know if this is me, maybe I don’t know how to use GlotPress in an efficient way, but I feel it is hard to use. I don’t think a project which is already translated should receive new suggestions, unless a validator admin wanted to change things in the whole translation. I’d like to be able to make only the new strings available to receive suggestions. Last release we had a problem with a string which in older versions was correct and now it is wrong. I don’t know what happend but somewhere in the process somebody suggested a wrong translation to something that was already translated before and this new wrong translation got approved. I think GlotPress is too focused on making the process a mechanical thing, while there’s a long way to become a good translation tool. We have our own glossary and it would be awesome to be able to search the translation for inconsistencies and to integrate this glossary to it, rather them having google translator which is useless, (at least for us, the translations suggested are awfull). Other improvement it lacks is to show the same string just once with all the suggestions to it, rather them to multiply it for each suggestion. It just makes our work as validators a nightmare. I know I can see all the suggestions to a string, but I need to click on it. It’s not efficient. And I think this could end the problem of the augmentation of page number. As a validator, I’d like to have control of which strings shouldn’t receive suggestions anymore. I’d like to see better level of role and capabilities. I’d like to setup a team of trusted translators with permissions to discard suggestions, but not with permissions to approve. I’d like to have a comments area where translators could discuss the best suggestions, etc. So, I really think it’s easier to do all this with poedit. You’ll say that I can do that and just import the po to GlotPress, but it’s hard to maintain, I can’t control if somebodyelse will send another suggestion meanwhile and make me have to proof read again.
        So, I don’t know. I’m not very happy with it.

    • Akerbeltz 10:11 am on April 5, 2012 Permalink | Reply

      For my part, I *am* thrilled – I’m one of those people good at translating but pretty much useless at doing code and the less hair everyone uses having people like me blunder around in svn and suchlike, the better. I don’t see why it shouldn’t work, after all, projects like LibreOffice use such an approach for a very large number of languages too.

    • Naoko 5:19 am on April 11, 2012 Permalink | Reply

      Now that we (Japanese team) built 3.4 beta 1 package, I realized that the method using GlotPress is missing one important feature: specifying the POT version and corresponding translations.
      Currently GlotPress only tags version by 3.2.x, 3.3.x, and so on. This means there is no tags for beta, alpha, RC, and point-release versions for translation files.

      We have been manually creating PO/MO to make sure the original POT version is the latest one for the creation of each WP core tag. Else we could end up with discrepancies between the latest GlotPress strings and that of the package we are trying to build, depending on the timing of the build.

      • Andrew Nacin 3:44 pm on April 11, 2012 Permalink | Reply

        This is a good point, Naoko. I am wondering, though, do you foresee this affecting major and minor releases? We will move wp/dev to wp/3.4.x upon release, and were we to do another 3.3 minor release, wp/3.3.x would be current (we haven’t changed a string in a minor release in a while).

        So, I only see this affecting alpha, beta, and RC. In which case, I am wondering if it is necessary. For us, a beta or RC package is nothing more than a snapshot in time. There is nothing wrong with releasing r20426 (HEAD) rather than the exact revision for 3.4-beta1. Anyone updating using the beta testing plugin would also not be getting the exact revision; it goes through the separate nightly build process.

        I think it’s an interesting aspect, but I just don’t know how important it is. What do you think?

        • Xavier 9:16 am on April 12, 2012 Permalink | Reply

          Most excellent point from Naoko.

          I do think it is important for translators to be able to release test package based in any arbitrary revision, if only to be able to tell local trusted users to test a version before the final release. We’ve done that in the past on our blog: “Help us proofread the translation!”

          There used to be official POT files for beta and RC versions a long time ago (http://svn.automattic.com/wordpress-i18n/pot/tags/), but the tradition has been lost, so translators now have to hope that the POT they are translating against does indeed match the revision they are building their test archive against.

    • Lopo 2:27 am on June 1, 2012 Permalink | Reply

      I don’t know if you have this in mind but having a similar link to how support forums work today for plugins/themes would be great.

  • Andrew Nacin 9:12 pm on March 2, 2012 Permalink | Reply
    nacin
    Tags: , , , , ,   

    Request for feedback from East Asian languages for WordPress 3.4 core modifications.

    In #8759, I’m looking for feedback for the editor word counts.

    In #16079, I’m looking for feedback for the length of auto-generated excerpts.

    If you could test the code and post in the relevant tickets, it would be much appreciated.

     

  • Andrew Nacin 9:55 pm on February 7, 2012 Permalink | Reply
    nacin
    Tags:   

    Need some RTL feedback here: http://core.trac.wordpress.org/ticket/6425. How should be be handling RTL content in RSS feeds?

     

    • geminorum 1:02 am on February 8, 2012 Permalink | Reply

      I think there is no need to add direction styles on the feed content. The readers usually support the RTL automatically, such as Google Reader and IE feed reader. Also, we’re usually apply the styles when fetching via code into the content, that is also RTL.
      The advantage is only for when mixing RTL and non-RTL feeds together.

  • Andrew Nacin 9:52 pm on February 7, 2012 Permalink | Reply
    nacin
    Tags: , ,   

    I’ve updated the list of 3.4 changes:

    • New: Localizing commas, as a tag separator
    • New: Fields that should always be LTR
    • New: Spellchecker language is now translatable
    • Changed: How precisely core detects that a language is RTL (it now uses a translated string)
     

  • Andrew Nacin 2:50 pm on January 31, 2012 Permalink | Reply
    nacin
    Tags: , ,   

    3.4 update: Localizing quotes and apostrophes that go through wptexturize(). More

     

    • Xavier 12:25 am on February 8, 2012 Permalink | Reply

      It seems the right place and time to comment about curly quotes.

      I made a quick update to my trunk install’s MO files, just enough to be able to check my curly quote break post. Still no cigar.

      This has long been a personal quest for me (I wrote some tests at the time), and has been pushed over and over, through many tickets with varying degrees of relevancy to the issue (AFAICT). Since there’s a lot of effort on i18n during this cycle, I would love it 3.4 could put an end to that issue.

      I can open a brand new ticket if need be.

      • Andrew Nacin 12:57 am on February 8, 2012 Permalink | Reply

        The bugs there are not i18n-related. They were nearly fixed in #4539 (for which the other ticket was closed as a duplicate), but the tests were not comprehensive enough and quite a few things broke, so it was backed out of trunk.

        So, no new ticket needed. Just look at #4539 and see if there is anything that can be done.

  • Andrew Nacin 9:27 pm on January 29, 2012 Permalink | Reply
    nacin
    Tags: ,   

    In 3.4, you no longer need any PHP to customize the defaults for start of week, feed language, or default timezone. (You would have hooked into populate_options for these.)

    start_of_week and timezone_string/gmt_offset are now translatable, and rss_language is gone (it uses the site’s locale, now).

    I’ve created a page here that outlines all changes to 3.4 so far, including the details for how to set these defaults: Important Changes for WordPress 3.4. I will update it as more changes happen.

     

  • Andrew Nacin 5:19 am on January 29, 2012 Permalink | Reply
    nacin
    Tags: ,   

    For 3.4, the default links are now translatable, both titles and URLs. http://core.trac.wordpress.org/changeset/19781

    I left out the URLs for extend/plugins/, themes/, and ideas/ from being translated as there are not yet official localized resources for these, and I would not want to send them off-site. Since the forums are a better conduit for feedback anyway, I demoted Suggest Ideas down the list, moving the Support Forums up one.

     

  • Andrew Nacin 8:48 pm on January 27, 2012 Permalink | Reply
    nacin
    Tags: ,   

    In GlotPress, you may need to export 3.3.x/ms strings and import them into dev.

    For 3.4, we’re changing how we split strings into multiple pot files. Since 3.0, we’ve done a generic POT and then a second POT for multisite. We are now going to be doing a frontend POT, an admin POT, and a network admin POT. The projects have been added to GlotPress here and here.

    While merging and splitting projects in GlotPress, some strings got orphaned. Before you go re-translate all of the missing strings, first go to translate.wordpress.org/projects/wp/3.3.x/ms, export a po file, and import it into both wp/dev/admin and wp/dev/admin/network. Everything should be back to normal.

    Cheers, and sorry for the trouble. For more, see ticket 19852.

     

  • Andrew Nacin 6:55 pm on January 27, 2012 Permalink | Reply
    nacin
    Tags: ,   

    In 3.4, you will no longer need to specify a $wp_default_secret_key, in $locale.php or in default-constants.php. For many of you, this means your $locale.php file will now be empty. Branch off 3.3 and remove $locale.php from /trunk/dist/ if that is the case. See ticket 19599 for more.

     

  • Andrew Nacin 8:38 pm on January 26, 2012 Permalink | Reply
    nacin
    Tags: ,   

    All locales: In 3.4, you will no longer need to override wp-admin/setup-config.php. The strings in this file will now be included in the POT, and the config file will be generated properly regardless of the wp-config-sample.php placeholders such as “your_username_here”. See [19760] and #18180.

     

  • Andrew Nacin 10:46 pm on January 25, 2012 Permalink | Reply
    nacin
    Tags: , , , , dv, , , ha, , ps, , , uz_UZ, yi   

    RTL locales: In 3.4, you will no longer need to specify $text_direction = 'rtl'; in your $locale.php file. Please remove it from $locale.php, and if this makes your $locale.php empty, then remove the file. (Please branch /trunk/ off into /3.3/ first, in case there is a 3.3.2.)

    The following locales have been included: ar, ckb, fa_IR, he_IL, ug_CN, dv, fa_AF, ha, ps, uz_UZ, yi. If you are missing (or are incorrectly included), let me know.

     

  • Andrew Nacin 9:10 pm on January 3, 2012 Permalink | Reply
    nacin
    Tags: ,   

    The release of 3.3.1 is imminent. It is a security and maintenance release. There are no new strings. Please deploy promptly. Thanks!

     

  • Andrew Nacin 10:49 pm on December 18, 2011 Permalink | Reply
    nacin
    Tags: , ,   

    Moving Locale-Specific Modifications into Core

    The core team is intending to propose for 3.4 that all locale-specific modifications get moved to core. Ideally, this will reduce all (or nearly all) packages to mo files, po files, and readme.html.

    What does that mean? All plugins, locale.php files, JS, CSS, etc., will all end up getting a complete review and become part of core. Any future changes will then take place with new versions of WordPress, and will be tracked on core Trac. Translation teams will still advise on, and ideally drive, any needed changes.

    I think it’s pretty clear as to why we’d like to go in this direction. This will happen in parallel with language packs. To get there, we will need to simplify the contents of localized packages. The end goal is to make things simpler for the user, but it also can set the stage for future features, and there are added benefits. One, the core developers will be investing time into problems that translation teams face. Two, translation teams will be prevented from solving complex problems on their own.

    We know that in some cases, core tickets for certain problems have rotted for some time, forcing hacks, filters, and plugins. We will not only addressing these, but by tackling these issues, we are making a commitment that extends beyond WordPress 3.4 that localized builds are a major player in the ecosystem.

    This is a major undertaking, and we will need your help.

    I would like to keep discussion here and pure implementation on Trac. However, to demonstrate how serious we are, and how large the scope of this project will be, here is an incomplete list of Trac tickets assigned to the project:

    • #8759 — “Word count” should could by characters in some locales.
    • #6425 — Support RTL in feeds.
    • #19597 — Allow translation of the bundled plugins’ descriptions.
    • #19598 — Text inputs for codes or URLs should be LTR.
    • #19599 — Localizations should not need to worry about the default secret key.
    • #19600 — Core should know which languages are RTL.
    • #19601 — Support localized defaults for options, links, dashboard widgets, etc.
    • #19602 — Curly quotes from wptexturize() should not be forced on all locale.
    • #19603 — Support locale-specific modifications in core (the catch-all ticket).

    I am going to need to have discussions with the fa_IR, ug_CN, ru_RU, zh_CN, ja, and eo locales, as you have complex bundled plugins and locale.php files. Some other locales may have particular concerns as well. We should schedule some public chats in #wordpress-polyglots for this, and to I intend to do a town hall style discussion on #wordpress-polyglots in a few weeks.

    Dion Hulse (dd32) is the other core developer on this project, and one of our rockstar contributing developers (and Russian maintainer) Sergey Biryukov will be heavily involved as well.

    So, any questions or comments? :-)

     

    • Zé 10:57 pm on December 18, 2011 Permalink | Reply

      Big title is big withdrawn

    • Xavier 11:16 pm on December 18, 2011 Permalink | Reply

      Great news! I’ll be able to help wherever I can.

    • Remkus de Vries 7:28 am on December 19, 2011 Permalink | Reply

      This is great news indeed! Even though you’re only mentioning core related locale, I assume this will also cover locale issues related to plugins like BuddyPress, BBPress and themes like Twenty Ten and Twenty Eleven?

      • Andrew Nacin 2:41 pm on December 19, 2011 Permalink | Reply

        Could you elaborate on the specific locale issues with plugins and themes?

        • Remkus de Vries 3:41 pm on December 19, 2011 Permalink | Reply

          The pain we now have to go through to use a translated version of BuddyPress and BBPress is not cool. It’d be great if this whole translation pack thing also included language for – particulary – two two plugins, but for instance, also the Twenty Ten, Twenty Eleven (and future Twenty Twelve) themes.

          Basiscally.. in an ideal world, whatever we translate on translate.wp.org for whatever end product, should be made available in an easy fashion for Joe Q. Public.

          If you need more input – because if have it if you need it – just let me know. You’ve got my Skype details ;)

          • Andrew Nacin 4:00 pm on December 19, 2011 Permalink | Reply

            Ah, yes. Language packs are a separate beast (and will also begin to be addressed in 3.4). This proposal is particular to locale-specific modifications of PHP, JS, or CSS.

    • Bage 10:22 am on December 21, 2011 Permalink | Reply

      In Tamil most of the time the “slug” get trimmed because of the character limitation. I hope this will happen to most of the languages using utf-8 characters.

      Is there anything can be done to fix this?

    • Kenan Dervišević 1:20 pm on December 21, 2011 Permalink | Reply

      @nacin Could you please take a look at these?
      http://wppolyglots.wordpress.com/2011/09/27/please-do-something-about-the-horrible-cache-function/
      http://wppolyglots.wordpress.com/2011/05/16/hello-i-was-building-a-new-beta1-version/
      http://wppolyglots.wordpress.com/2011/11/26/hello-i-just-noticed-that-untranslated-messages-arent/

      Also, there is one annoying bug when building localization packages. When you change source from “Subversion” to “translate.wordpress.org” (or the other way around) option “WordPress branch” grays out and, when you click a button to build a package, you get “Invalid source…” error.
      http://pokit.org/get/?311a03b788899de5f47a9d2aef238b79.png
      http://pokit.org/get/?15a764bd5d2e0f3d1e990ba95398ce3b.png

      And, i18.trac.wordpress.org is missing a logo and encoding is not set as UTF-8.

    • codestyling 5:29 am on May 27, 2012 Permalink | Reply

      This is not the complete handling for locale specific modifications. Let me explain an example from german special needs. It’s common use to have 2 distinct translations of the same source base: formal and informal type of *.mo files.

      But there is no build in support at WordPress at all for such a kind of modifications. I would prefere to modify WordPress language handling to cope with this as standard instead of letting plugins like woocommerce going their own way and loading this 2 types on user demand from different folders.
      This leads to homebrew implementations not standardized and plugins/themes will start either to copy this behavior or to implement their own way copying with this. Serveral misbehavior will follow asap.

      To avoid that and also have a solution valid and common use for all (WordPress Core, Plugins and Themes) following additional changes should be made:

      1.) deprecate the usage of WPLANG constant at wp-config.php file and replace it with the same type of usage introduced for multisite installations. Let the user choose it at the backend settings either its multisite or not. For single WordPress installations at a dedicated language just extend the initial database setup to pre-insert (update) the locale at the option table during install.

      2.) extend the backend settings to have a checkbox (or more flexible a selectbox) to choose the type of locale file to use if available. This should provide something like “formal”, “informal” ect. and should default to the current behavior at loading language files.
      Currently a WordPress file will be loaded by creating the filename as “/wp-content/languages/de_DE.mo” but respecting the new user option for types it could also load “/wp-content/languges/de_DE-formal.mo” file and default back to the standard locale file, if type based file is not available.

      3.) extend all the load_textdomain based functions to cope with the type of locale file. This will ensure, that we have a standard way how locale specific types of language files can be easily used by blog owners and also gives a common WordPress standard for all Theme and Plugin Authors they can implement into their code.

      I’m sure, there are some other locales also would be happy, if the could load different types of language files for the same locale. It could also as extended as a plus on top with a filter, that can enlarge the available types of language files for the choice list.

      Please let me know, if you think, this would also make WordPress more straight forward, common defined and more flexible. In my opinion it reduces the support requests, defines the standard ways and avoid growing homebrew solutions within plugins/themes.

      • Remkus de Vries 8:15 am on May 27, 2012 Permalink | Reply

        Never gave it that much thought and even though we have chosen to go with the informal version of Dutch for our translation, we do have the same issue. There are numerous sites out there in Dutch that now have to use the informal translation, but really would be better of with the formal one (think government sites for example). So a +1 from me.

  • Andrew Nacin 2:43 pm on December 18, 2011 Permalink | Reply
    nacin  

    “Translate from Google” — Did it get any use by you guys? Did not having it slow you down? Did not having it improve quality? Would anyone like it back?

     

    • Remkus de Vries 2:45 pm on December 18, 2011 Permalink | Reply

      Used it a lot. For Dutch the basic translation was not too bad and a good base for the proper translation.

    • Zé 3:00 pm on December 18, 2011 Permalink | Reply

      We (pt_PT) have no use for it. It’s generally (and consistently) inaccurate, and a nightmare for validators. There’s this, too: http://glotpress.trac.wordpress.org/ticket/170

      • Andrew Nacin 3:04 pm on December 18, 2011 Permalink | Reply

        It probably should no longer be in GlotPress core, but we can pull it into a plugin, and we’re willing to switch to the paid version if there is demand for it.

      • Rafael Poveda - RaveN 3:21 pm on December 18, 2011 Permalink | Reply

        We can say the same for es_ES. It’s inaccurate and mixes all-sites spanish (Venezuela, Peru, Spain, etc). And some newbie translators are used to ‘Translate all with Google’, which gives much more work than empty strings.

        We are not going to miss this button ^_^.

    • Zé 4:00 pm on December 18, 2011 Permalink | Reply

      A more detailed take, from the point of view of latin languages (I understand that languages closer to English might not have the same opinion):

      • It’s a poor quality machine translation
      • It mixes variants of a language on the same text, i.e. European Portuguese and Brazilian Portuguese, not to mention pre- and post-ortography reform within the same language
      • Whatever gets mistranslated, is always mistranslated in the same way, GT doesn’t learn
      • Contributors are too often tempted to click the GT button and leave it at that, especially when there are lots of strings to translate. This is a nightmare for validators, who end up having to do it all over again

      In short, some kind of GP-internal glossary functionality would be way more useful than Google Translate or Bing Translate (which suffers from the same ailments).

    • Remkus de Vries 4:02 pm on December 18, 2011 Permalink | Reply

      I suppose that a lot of our bad translations might stem from people using GT. Not sure, but when I think about it is sounds logical. It’s only a good tool when you know how to handle it I guess.

    • Toru 4:17 pm on December 18, 2011 Permalink | Reply

      Never used if for translating to Japanese. Google translation is ok sometimes to just to get a grasp of what some sentece say, but usually useless for “proper” translation. Personally, not going to miss at all.

    • yuraz 6:05 pm on December 18, 2011 Permalink | Reply

      I didn’t used it at all for Croatian because it’s inaccurate. I can live without it, won’t miss it.

    • Mattias Tengblad 7:59 pm on December 18, 2011 Permalink | Reply

      I can live without it, GT is ok for Swedish but still has a lot to wish for. It was kind of useful for larger texts like Remkus de Vries pointed out.

      Totally agree with Zé ^

      GP-internal glossary functionality similar to PoEdit’s Automatic Translation using Translation Memory, which would be teh awesome.

    • Xavier 9:50 pm on December 18, 2011 Permalink | Reply

      fr_FR translators hardly ever use GlotPress (sorry!); we rely on the tried-and-true Poedit+SVN formulae, which is how we like to work (yup, we’re old and grumpy). We also tend to translate everything by hand, and not rely on anything automatic (not even Poedit’s tools — hence my non-opinion on Zé’s suggestion re: Poedit’s ATuTM).

      In general, I use translate.google.com (not GP’s button) for three contexts:

      single words, in order to get multiple suggestions.

      unknown expression, in order to understand a specific part of a string (remember the “kitchen sink” button? Good times!).

      Lonnng strings, in order to get started by correct something badly translated instead of the whole text itself.

      It is my opinion that none of these three context can be properly answered with the “Translate from Google” button. As others have noted, it brings further risks of having lazy contributors just click the button and leave it at that in order to be done with it quicker, which really hinders the improvement of the whole translation.

      Ergo, I’m all for dropping it.

      • Sergey Biryukov 11:00 pm on December 18, 2011 Permalink | Reply

        I’m currently using Poedit too (suits my workflow best). Never used GT button.

    • Carlos Eduardo G. Barbosa 10:10 pm on December 18, 2011 Permalink | Reply

      Never will use it. It’s a guess tool, not a translation tool.
      Never will miss it.

    • Gabriel Reguly 1:33 am on December 19, 2011 Permalink | Reply

      A glossary would be of more use, if it is possible to ask for one.

    • Rami 10:43 am on December 19, 2011 Permalink | Reply

      i was using it a lot, although the auto-translate requires many changes, it saves me time. i would like it back.

    • Torsten 10:54 am on January 15, 2012 Permalink | Reply

      It was a time saver if you start a translation, but it is a time killer if you have to reject/correct bad translations (if a newbie just clicked the GT button …). I would like to have a button for auto-translation, but it has not to be GT. An internal GlotPress solution would be the best.

← Older posts

Newer posts →

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