• Hello @petrnovak
    The way you have prepared this plugin for translation will not work for some 40% of all WordPress sites.

    The reason is that if a WordPress site is set to the “en_US” locale, WordPress will right away use all strings in the plugin as they are, without any translation.

    At the same time, the Polyglots’ volunteer team uses “US English” as its common denominator. When we check that translations are correct, we can only do that if the source strings are in English.

    In other words, if you want your plugin to be useful in English and be possible to localize, please change all visible strings to US English in the plugin.

    With regards to how this plugin is (not) prepared for translation, you should expect most locale teams to reject all your translations in bulk. The simple reason is that they are incorrect. The only way we could “translate” something like help-output-table-column-3 would be to just copy the source string to the target.

    FYI:
    #ru_RU #cs_CZ #de_DE #es_ES #fr_FR #id_ID #it_IT #ja #nl_NL #pl_PL #pt_BR #tr_TR

Viewing 11 replies - 1 through 11 (of 11 total)
  • I already rejected all strings, as we cannot accept this. There is no way, we can check that the translations are correct for nl_NL

    And we rejected all the lines.

    #pl_PL rejected

    #cs_CZ rejected

    de_DE rejected

    #it_IT rejected

    #es_ES rejected

    Plugin Author Petr Novak

    (@petrnovak)

    Hi @tobifjellner, thank you for your feedback! 🙂

    I’m aware that English is the standard for source strings. I chose this approach specifically to better manage various currency code formats across different locales. To assist with translation, I’ve included comments in the source code for each string with context and the English equivalent.

    The plugin already includes translations for the listed languages. My testing (including locales like de_CH, en_AU, or es_CL) confirms that the WordPress fallback system works correctly in these cases.

    Thank you very much for your time and help! 🙂
    Petr

    It is great that you have decided to take a creative approach, but please do it where it doesn’t affect other people.

    You have hundreds of strings like this “templates-success-default-set” where there is absolutely no clue for translators about context.

    The corresponding code is a misuse of the gettext functions without any possible justification.

    set_transient( 'smart_convert_currency_unit_conversion_template_flash', array(
    'status' => 'success',
    'message' => __( 'templates-success-default-set', 'smart-convert-currency-unit-conversion' )
    ), 30 );



    Originals like this, will not be accepted by us in nl_NL. So PTE request will not be given. There is no way we can check, if the translation is done correctly.

    Plugin Author Petr Novak

    (@petrnovak)

    Hi there,

    thank you for your feedback. I completely understand your concerns regarding the lack of context and the misuse of gettext functions.

    I have addressed these issues in the latest update:

    1 – Human-readable Strings: I have replaced the abstract slugs (like templates-success-default-set) with actual English phrases.

    2 – Translator Comments: To ensure there is no guesswork, I have added descriptive comments (translators’ notes) to all strings to provide clear context for each message.

    3 – Best Practices: The code has been refactored to align with standard localization practices, ensuring that the original text is clear and verifiable.

    I hope these changes meet the requirements for requests. Please let me know if any further adjustments are needed. 🙂

    Best,

    Petr

Viewing 11 replies - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.