Forum Replies Created

Viewing 1 replies (of 1 total)
  • Hi @rdenaultcpdlp,

    Thank you for such a precise report. Both problems were exactly as you described, and both are fixed in 2.98.0, which is available now

    1. Strings that couldn’t be translated. You found three, and there were more of the same kind: “Copied!”, “Load more (n)”, the Previous/Next and page-number buttons, and the palette’s “Searching…”, “Search is unavailable right now.” and “No matching documents.”. As you suggested, they all come from PHP now, through filedeckL10n and filedeckPalette, so an ordinary .po/.mo translation covers them. The build also now fails if an English string is written straight into the plugin’s JavaScript again.

    A note on the markup, FileDeck doesn’t output data-no-translation or data-no-translation-aria-label. Those are TranslatePress’s own markers, which it adds to text that has already been through WordPress’s translation functions, so that it doesn’t translate that text a second time. They don’t stop a .po/.mo file from working.

    1. No .pot file. The plugin now ships languages/filedeck.pot, generated with WP-CLI’s make-pot. Loco builds its string list from it, so the 100 KB scan limit no longer matters, and the list includes the strings above and the block editor’s labels. If you’ve already started a fr_CA translation, open it in Loco and click Sync to pull in the new strings.

    Also relevant to your site: FileDeck has bundled a French translation since 2.94.0, but only as fr_FR, and WordPress doesn’t fall back from fr_CA to fr_FR, so it never loaded for you. The update ships it as fr_CA too. If your own translation is saved in Loco’s Custom or System location, your wording is what visitors see. If it’s in the Author location (the plugin’s own languages folder), move it before updating, because an update replaces that folder.

    Thanks again.

Viewing 1 replies (of 1 total)