WordPress.org

Ready to get started?Download WordPress

Forums

Loco Translate
[resolved] Issue with translating Gravity Forms (9 posts)

  1. Nick Ciske
    Member
    Posted 3 months ago #

    I was stumped at to why my translation for Gravity Forms was not working.

    And then I looked in the languages directory:

    gravityforms-xx_XX.mo

    Hmmm... that doesn't work when Loco Translate outputs xx_XX.mo.

    Sure enough, adding the prefix made the translations show up.

    I looked at a few more plugins and Advanced Custom Fields does this too: acf-xx_XX.

    Now I think GF is the odd one here, but it appears that being able to specify a prefix (or to indicate the textdomain should be prefixed to the .mo file) would be a useful option.

    Or perhaps outputting both (just to be safe)?

    https://wordpress.org/plugins/loco-translate/

  2. timwhitlock
    Member
    Plugin Author

    Posted 3 months ago #

    Hello.
    I hope I've interpreted your issue correctly here.

    Are you saying that Loco outputs domainless PO and MO files even though existing PO files in the directory are prefixed correctly?

    As a rule, Loco will always prefix files with the textdomain for plugins, BUT it will attempt to copy the style that is already being used. So if you have domainless PO files already in the directory it will assume that's want you want and copy the style.

    That bit of code is here, if you're interested.

    Perhaps there is a bug, but I just need to be sure whether this is expected behaviour or not. Can you send me a link to a free plugin that suffers from your problem and I'll try it out?

  3. Nick Ciske
    Member
    Posted 3 months ago #

    Yes, existing files are gravityforms-fr_FR.mo.

    The Korean files I created with Loco were domainless: ko_KR.po & ko_KR.mo

    It does pick up the existing languages for ACF (so it must be something different about Gravity Forms in that regard).

    But... when I create a new Korean language file for ACF... it gets created as: ko_KR.po & ko_KR.mo not acf-ko_KR.po & acf-ko_KR.mo.

    It it helps:
    WP 3.8.1
    Multisite
    WP Engine

    ACF
    http://wordpress.org/plugins/advanced-custom-fields/

  4. timwhitlock
    Member
    Plugin Author

    Posted 3 months ago #

    Ok, I'll look into this with acf.

    Which version of Loco Translate are you using?

  5. Nick Ciske
    Member
    Posted 3 months ago #

    Ah, I see the issue:

    // only prefix with text domain for plugins and files in global lang directory
            if( 'plugin' === $this->get_type() || 0 === strpos( $dir, $this->_lang_dir() ) ){
                $prefix = $domain.'-';
            }
            else {
                $prefix = '';
            }

    So Loco is saving these files in the plugin's language folder -- so it's not using the prefix (though it appears the plugin authors are, regardless of location).

    So is the real issue the lang folder and not the path?

    Am I missing something? My root languages folder is /wp-content/languages/ - I just defined that explicitly in wp-config and Loco still stored the po/mo in the plugins language folder.

  6. Nick Ciske
    Member
    Posted 3 months ago #

    Latest. Just installed it last night ;-)

  7. timwhitlock
    Member
    Plugin Author

    Posted 3 months ago #

    I think the wording of my comment may be confusing.

    only prefix with text domain for plugins and files in global lang directory

    should perhaps be:

    prefix with text domain for all plugins and for any files in global lang directory, but not for themes in their theme directory.

    The first block should be used because your package is of type 'plugin'.
    I'll debug this properly and let you know when I can reproduce it.

  8. timwhitlock
    Member
    Plugin Author

    Posted 3 months ago #

    This was incredibly simple. A typo here:
    https://github.com/loco/wp-loco/commit/72d43ea108eb073a2e8449f8d22c90fd02782743

    so actually not related to specific plugins, but a silly bug missed through not testing thoroughly enough.

    I've made an emergency fix to the current version and should be fine in future versions too.

  9. Nick Ciske
    Member
    Posted 3 months ago #

    Happens to the best of us. Glad I could help squash it!

Reply

You must log in to post.

About this Plugin

About this Topic

Tags

No tags yet.