Comments (7)
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.
from grunt-wp-i18n.
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?
from grunt-wp-i18n.
I know what you mean about not having time! Let me know if you ever get that rolled into the language tools, though.
from grunt-wp-i18n.
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).
from grunt-wp-i18n.
Maybe @stephenharris is interested to work with "us" on a function to export strings that fall into report_missing
to json/log? 😈
from grunt-wp-i18n.
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.
from grunt-wp-i18n.
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.
from grunt-wp-i18n.
Related Issues (20)
- Ignore certain domain (e.g. via an options.dontUpdateDomains) HOT 12
- Warning: Cannot read property 'split' of undefined HOT 6
- Exclude page templates HOT 3
- "updateTimestamp: false" is not working properly HOT 3
- Exclude doesn't included in .pot file HOT 2
- Send modified files to build path only HOT 2
- Not Working on Windows ver > 8
- Good way to eliminate duplicates in pot file HOT 8
- Running "makepot" task keeps running forever HOT 4
- update node-wp-i18n to v1.0.5 HOT 1
- updateTimestamp: false not working HOT 8
- Detecting msgid stored in variable HOT 1
- Warning: Cannot read property 'pot-creation-date' of undefined Use --force to continue. HOT 1
- POT File by text domain HOT 2
- Switch to using `wp i18n make-pot` HOT 6
- Makepot supports for monorepo plugins HOT 1
- Addtextdomain throws error HOT 1
- Better output when makepot fails due to missing PHP cli
- Warnings when running on PHP 8 HOT 2
- Duplicate text domains added where text domain already exists HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from grunt-wp-i18n.