Exclude strings WITHOUT textdomain

[cfoellmann]

If a string is in the wp core translation files it is sometimes feasible to use it to improve translation consistency. Any idea how to filter out these strings used in the plugin/theme?

[bradyvercher]

The text domain isn't used by the core tools when extracting strings, so it wouldn't be possible unless you maintain a list and manually filter them out in the processPot callback.

Otherwise, if you don't have a lot of duplicate strings, then leaving them in the POT file may not be a big deal since the core translations would be used anyways. I suppose you could add a translators comment before them letting translators know they don't need to be translated, too.

[cfoellmann]

Thanks for the fast response. Might investigate to contribute this to the language tools in the future. But who got the time for everything, right?

[bradyvercher]

I know what you mean about not having time! Let me know if you ever get that rolled into the language tools, though.

[marcochiesi]

I used the following snippet inside processPot handler to exclude a few static strings:

                        var translation, exclude = [ 'String 1', 'String 2', 'String 3' ];
                        for ( translation in pot.translations[''] ) {
                            if ( exclude.indexOf( translation ) >= 0 ) {
                                delete pot.translations[''][translation];
                                console.log( 'Excluded string: ' + translation );
                            }
                        }

Unfortunately this is hardcoded and not automated. I tried to integrated with the checktextdomain log, as suggested by @cfoellmann, but it does not save the strings without text domain in the log (it just saves references to them).

[cfoellmann]

Maybe @stephenharris is interested to work with "us" on a function to export strings that fall into report_missing to json/log? :smiling_imp:

[stephenharris]

Yeah, at the moment the log only reports references (it's intended purpose was for testing the code).

The fact that these plug-ins give errors when you are intentionally missing the textdomain so as to use core's translation is something I've come across too (and has prompted me to skip the missing textdomain check). However, I've come to consider piggy-backing off core's translations as the wrong thing to do.

There are obvious "context" problems where you are translating homographs, but these aside there is also the 'odd behaviour' that your plug-in/theme is then only partly translated. A plug-in which is half-translated will arguably appear more broken than one that is consistently in English. (The only counter-argument to this that your plug-in should be indistinguishable from 'core' to your average user).

Originally I reverted to core's translations so that my plug-in(s) didn't have to rely so much on volunteers for translations, and to reduce the amount of work those volunteers had to do. However, I have found people are usually more than willing to put the effort in.

[cfoellmann]

I have heard the argument against using core strings and I understand it. I see it a little different: you should always strive for a consistent "tone" in translations and it is hard enough to find translators to consistently monitor translations. So I think using core stings might not be the "right" but the most practical thing to do. Since nearly all plugins have missing translated strings in their translations (de_DE for me) I think every string from core that works for the context should be used (saves resources, too ;-) every bit counts).

One point against my arguments: just used transifex for the first time and it has a nice suggestion feature feeding from previous translations. Don't know if it works across projects if so it would be easy to just take the core translation of an equal string with one click.