Forum Replies Created

Viewing 15 replies - 1 through 15 (of 3,989 total)
  • Plugin Author Tim W

    (@timwhitlock)

    So the final question: What would happen if (1) in src/package/Debugger.php:186 is changed to …

    Nothing would happen to how it displays. It will print the exact same English text. If you format your German the same way it will print the exact same German text.

    What would happen is any existing translations of the original text will have to be fuzzy merged, or they would be dropped. Hence my reluctance to make a redundant change.

    For completeness it should probably have been written as ‘%1$s strings extracted from source code for “%2$s”‘, but this change would be equally redundant. I will try to observe this style in future for new strings.

    As I’ve also said, you are free to write your German placeholders anyway you like. If GlotPress shows a warning then it must only be doing a trivial comparison and doesn’t know they are actually equivalent. I do not use GlotPress and cannot comment on its capabilities.

    If people in larger numbers start asking me to change the formatting of existing source strings to fall in line with some particular best practice then I will. But for now, existing sources will stay as they are unless the wording needs to change.

    I thank you for all your feedback and I have already modified some translator comments as you suggested. However this issue has used over an hour of my time and I really don’t have anything more to say on the matter.

    Plugin Author Tim W

    (@timwhitlock)

    I cannot offer you any help with this kind of problem, or guess at what is going wrong. My plugin is a file editor. This is where its job begins and ends. What happens to the translations you save is then handled by the themes/plugins that use them.

    You could try the FAQs for clues: https://localise.biz/wordpress/plugin/faqs

    Plugin Author Tim W

    (@timwhitlock)

    Plugin Author Tim W

    (@timwhitlock)

    I have looked closely, and I don’t see any problem.

    At the moment that plural phrase gives me:
    %s strings found in %s
    which might wrongly be: 3 strings found in 3

    No. It won’t. Where are you seeing it render like this?

    The following are equivalent in PHP:

    %s strings found in %s
    %s strings found in %2$s
    %1$s strings found in %2$s

    None of these can possibly render “3 strings found in 3”. This is easily proven with this script:

    <?php
    printf("%s strings found in %s\n",3,'filename.po');
    printf("%s strings found in %2\$s\n",3,'filename.po');
    printf("%1\$s strings found in %2\$s\n",3,'filename.po');
    

    An example of an incorrect string would be this:

    %1$s strings found in %s

    That would print “3 strings found in 3” as you can see with this script:

    <?php
    printf("%1\$s strings found in %s\n",3,'filename.po');
    Plugin Author Tim W

    (@timwhitlock)

    Shouldn’t it be:
    %s strings extracted from source code for “%2$s”

    In this case they are equivalent. PHP allows positional arguments to be implied by sequence. It is required in the singular because I have chosen to NOT display the 1 in English, hence 2$ is required to skip it. You are free to write this in your translation any way you like as long as it renders correctly. It might be better style for me to write all strings with full positional arguments, but changing the source string would be unnecessary at this point in my opinion, because all existing languages would have to fuzzy merge the change.

    or to provide better understandable quote-signs for all translators (because various languages have different preferred quote-signs):
    %s string extracted from source code for “%2$s”

    I’m not sure I follow 100% here, but as a programmer I tend to use ASCII double quotes. My designer/writer friends like to get angry about this and prefer Unicode quote marks. I’m afraid I am not going to get into a debate about this, and as per my points above, it seems unnecessary to change the source strings when they are already translated. Again you are free to localise quote marks as you see fit in your translations.

    Plugin Author Tim W

    (@timwhitlock)

    Thanks for your hard work, but I don’t maintain any translations of my plugin. Releases of Loco Translate do not include translation files.

    The community translation projects that you link to belong to WordPress and I am not involved. Please report any problems to the German team, or ask to join them if you wish to contribute.

    Apologies. I skim read this. You are referring to source text. I will review now.

    Plugin Author Tim W

    (@timwhitlock)

    Either the theme author is using an incorrect date formatting string, or your WordPress settings are configured with an incorrect date formatting string.

    The responsibility of the file editor is to save the string “%1$s à %2$s” which it has done. Substituting the two placeholders with the correctly formatted date is not a matter related to using my plugin, or any other PO editor.

    Plugin Author Tim W

    (@timwhitlock)

    And the other two things I suggested?

    Do you have another plug-in installed that modifies Loco Translate?

    Is your install broken? Try reinstalling.

    And you’ve emptied your browser cache or done a hard reload?

    Plugin Author Tim W

    (@timwhitlock)

    its configuration can be found under Settings > WooCommerce Infinite Scroll

    Plugins that maintain custom strings within configurable options tend to break WordPress localisation. Once the option is saved, that’s it. That’s what you see. The idea is that you enter your translations into these options. If you have multiple languages then you would have to have a separate site per language to set separate options.

    This is bad practice in my opinion, but regardless of what I think the issue is beyond my control and not related to my plugin. I provide a PO editor. If plugins don’t use the strings in PO files then it’s of no use.

    I’ve created the new language entry but the plugin just recognizes 5 strings and not the all of the strings.

    This means Loco Translate hasn’t been able to extract any strings from the source code, which you shouldn’t be doing anyway unless you are the author of the plugin. See Working with POT files in Loco Translate and the related links.

    Plugin Author Tim W

    (@timwhitlock)

    Error: path argument required

    To see this error you would have to be running an old version of the JavaScript (editor.js). Either because it is cached in your browser, cached in a CDN (if you’re using one), modified by another plugin, or for some reason WordPress didn’t update it properly. I can’t guess at which is the cause, but if editor.js is up to date the error will go away.

    and now the whole site appears in English.

    This is unlikely to be related to the error above. Possibly related FAQ: https://localise.biz/wordpress/plugin/faqs/files-deleted

    Plugin Author Tim W

    (@timwhitlock)

    I don’t see how it could, but as I have no idea what your problem is I can’t rule anything out.

    As you are evidently out of your depth and in desperate need of a solution quickly, I urge you to use another PO file editor that you are able to run on your server or offline.

    Plugin Author Tim W

    (@timwhitlock)

    May I recommend with 30 websites that you come up with a better test and deploy strategy than relying on WP updates. Any plugin you update could contain errors, incompatibilities or conflicts.

    Thanks for marking resolved.

    Plugin Author Tim W

    (@timwhitlock)

    If there are files missing from my plugin due to a bad install process then please mark this issue as resolved as clearly the plugin is not at fault in this regard.

    If you find there is a real error coming from my plugin then feel free to post it any time.

    Plugin Author Tim W

    (@timwhitlock)

    My plugin is not capable of “destroying” your website.

    If there is an error please try to find some useful messages in your log files.

    Plugin Author Tim W

    (@timwhitlock)

    Why can’t you simply use the CODE button? Pictures are no use when I need to copy and paste the text to check it for errors.

    Anyway.. it looks at a glance like perfectly valid JSON and not an error response. I have no idea why jQuery is refusing to parse it and is instead invoking its error handler. Possibly bad headers, but I’d be guessing.

    Are you able to look into the network inspector and post the full HTTP response headers? In particular to see if the response has a valid Content-Type and Content-Length

Viewing 15 replies - 1 through 15 (of 3,989 total)