New to Translating WordPress? Read through our Translator Handbook to get started. Hide

Translation of Stable Readme (latest release): Russian

Filter ↓ • Sort ↓ • All (230) • Translated (1) • Untranslated (229) • Waiting (0) • Changes requested (0) • Fuzzy (0) • Warnings (0)
← 1 2 3 … 16
Prio Original string Translation —
↑ No more SPAM by spiders scanning your site for email addresses!
Priority: high
You have to log in to add a translation. Details
No more SPAM by spiders scanning your site for email addresses!
Comment

Short description.

You have to log in to edit this translation.

↑ CryptX
Priority: high
You have to log in to add a translation. Details
CryptX
Comment

Plugin name.

You have to log in to edit this translation.

On a network both take <code>--url</code>, so <code>wp site list --field=url | xargs -I{} wp cryptx scan --url={}</code> covers the whole network. You have to log in to add a translation. Details
On a network both take <code>--url</code>, so <code>wp site list --field=url | xargs -I{} wp cryptx scan --url={}</code> covers the whole network.
Comment

Found in faq paragraph.

You have to log in to edit this translation.

What the scan does not cover: widgets, comments, feeds, and anything a theme prints on its own. It is a check on your posts and pages, not a clean bill of health for the whole site. You have to log in to add a translation. Details
What the scan does not cover: widgets, comments, feeds, and anything a theme prints on its own. It is a check on your posts and pages, not a clean bill of health for the whole site.
Comment

Found in faq paragraph.

You have to log in to edit this translation.

It reads the body and the title of each post, and a "where" column says which of the two. Titles matter here because CryptX cannot protect them: a title goes into the document head through WordPress itself, along a path no plugin filter touches. An address in a post title is readable, and the only fix is to take it out of the title. You have to log in to add a translation. Details
It reads the body and the title of each post, and a "where" column says which of the two. Titles matter here because CryptX cannot protect them: a title goes into the document head through WordPress itself, along a path no plugin filter touches. An address in a post title is readable, and the only fix is to take it out of the title.
Comment

Found in faq paragraph.

You have to log in to edit this translation.

Yes, with WP-CLI. <code>wp cryptx settings</code> lists every setting with its current value; <code>wp cryptx settings &lt;name&gt;</code> reads one and <code>wp cryptx settings &lt;name&gt; &lt;value&gt;</code> writes it, through the same validation the settings screen uses. You have to log in to add a translation. Details
Yes, with WP-CLI. <code>wp cryptx settings</code> lists every setting with its current value; <code>wp cryptx settings &lt;name&gt;</code> reads one and <code>wp cryptx settings &lt;name&gt; &lt;value&gt;</code> writes it, through the same validation the settings screen uses.
Comment

Found in faq paragraph.

You have to log in to edit this translation.

Two settings are missing from that screen on purpose. The list of excluded post IDs and the uploaded image both refer to things that exist on one site only: post 17 on one site has nothing to do with post 17 on another, and copying that list would exclude the wrong posts -- which is precisely what left addresses unprotected on some networks before 4.1.1. You have to log in to add a translation. Details
Two settings are missing from that screen on purpose. The list of excluded post IDs and the uploaded image both refer to things that exist on one site only: post 17 on one site has nothing to do with post 17 on another, and copying that list would exclude the wrong posts -- which is precisely what left addresses unprotected on some networks before 4.1.1.
Comment

Found in faq paragraph.

You have to log in to edit this translation.

The settings live per site, because that is where the addresses and the design live. A site administrator configures their own site as usual. Since 4.2.0 a network administrator can set the defaults a newly created site starts with, under Network Admin / Settings / CryptX -- a starting point, not an instruction: sites that already exist are never changed by it, and a site administrator can change theirs at any time. You have to log in to add a translation. Details
The settings live per site, because that is where the addresses and the design live. A site administrator configures their own site as usual. Since 4.2.0 a network administrator can set the defaults a newly created site starts with, under Network Admin / Settings / CryptX -- a starting point, not an instruction: sites that already exist are never changed by it, and a site administrator can change theirs at any time.
Comment

Found in faq paragraph.

You have to log in to edit this translation.

An address such as "post@münchen.de" is not protected -- CryptX looks for addresses using the ASCII form, so it does not recognise one with an accented or non-Latin domain in the first place. Write the domain in its punycode form ("post@xn--mnchen-3ya.de") and everything works as usual. The editor block says so where you type it; elsewhere the address is simply left as it was. You have to log in to add a translation. Details
An address such as "post@münchen.de" is not protected -- CryptX looks for addresses using the ASCII form, so it does not recognise one with an accented or non-Latin domain in the first place. Write the domain in its punycode form ("post@xn--mnchen-3ya.de") and everything works as usual. The editor block says so where you type it; elsewhere the address is simply left as it was.
Comment

Found in faq paragraph.

You have to log in to edit this translation.

Two neighbouring settings answer different questions. The list of endings ("jpeg,jpg,png,gif") is what keeps file names such as logo@2x.png from being mistaken for an address in the first place. The list of post IDs switches CryptX off for a whole post or page. You have to log in to add a translation. Details
Two neighbouring settings answer different questions. The list of endings ("jpeg,jpg,png,gif") is what keeps file names such as logo@2x.png from being mistaken for an address in the first place. The list of post IDs switches CryptX off for a whole post or page.
Comment

Found in faq paragraph.

You have to log in to edit this translation.

That distinction rests on which filter the text arrives through, and only comments can be told apart with certainty. Forum and front-end submission plugins -- bbPress and BuddyPress among them -- send what a visitor wrote through the same filter as your own posts, so the domain form does apply there. If your site takes text from visitors that way, exempt the individual addresses rather than a whole domain. You have to log in to add a translation. Details
That distinction rests on which filter the text arrives through, and only comments can be told apart with certainty. Forum and front-end submission plugins -- bbPress and BuddyPress among them -- send what a visitor wrote through the same filter as your own posts, so the domain form does apply there. If your site takes text from visitors that way, exempt the individual addresses rather than a whole domain.
Comment

Found in faq paragraph.

You have to log in to edit this translation.

There are two limits on purpose. Inside <code>[cryptx]...[/cryptx]</code> -- and inside the "Protected email address" block, which is the same instruction in a different shape -- nothing is exempt: it says "protect this one, here", and a setting made months ago on another screen is not an answer to that. Where the shortcode is written somewhere WordPress never expands it, such as a hand-written excerpt, this reaches a little further: an exempt address standing next to it in the same text is protected as well. That is the harmless direction, but worth knowing if you exempted an address precisely so a machine could read it. And in comments only a whole address counts, never the domain form -- otherwise exempting your own domain would hand out every address at that domain a visitor happened to leave in a comment. One more thing worth knowing about comments: WordPress itself turns a bare address into a link before CryptX ever sees it, so an exempt address stays readable there but does become a link. You have to log in to add a translation. Details
There are two limits on purpose. Inside <code>[cryptx]...[/cryptx]</code> -- and inside the "Protected email address" block, which is the same instruction in a different shape -- nothing is exempt: it says "protect this one, here", and a setting made months ago on another screen is not an answer to that. Where the shortcode is written somewhere WordPress never expands it, such as a hand-written excerpt, this reaches a little further: an exempt address standing next to it in the same text is protected as well. That is the harmless direction, but worth knowing if you exempted an address precisely so a machine could read it. And in comments only a whole address counts, never the domain form -- otherwise exempting your own domain would hand out every address at that domain a visitor happened to leave in a comment. One more thing worth knowing about comments: WordPress itself turns a bare address into a link before CryptX ever sees it, so an exempt address stays readable there but does become a link.
Comment

Found in faq paragraph.

You have to log in to edit this translation.

Yes. Under Settings / CryptX / Exceptions there is a list of addresses to leave alone. Write "info@example.com" for a single address, or "@example.com" to cover every address at that domain. CryptX leaves those addresses exactly as written -- it does not mask, link or encrypt them -- which is what you want for an address a helpdesk has to read out of the page, or one shown in a code example. You have to log in to add a translation. Details
Yes. Under Settings / CryptX / Exceptions there is a list of addresses to leave alone. Write "info@example.com" for a single address, or "@example.com" to cover every address at that domain. CryptX leaves those addresses exactly as written -- it does not mask, link or encrypt them -- which is what you want for an address a helpdesk has to read out of the page, or one shown in a code example.
Comment

Found in faq paragraph.

You have to log in to edit this translation.

Can I use CryptX from the command line? You have to log in to add a translation. Details
Can I use CryptX from the command line?
Comment

Found in faq header.

You have to log in to edit this translation.

What about addresses at an internationalised domain? You have to log in to add a translation. Details
What about addresses at an internationalised domain?
Comment

Found in faq header.

You have to log in to edit this translation.

Legend:
Current
Waiting
Rejected
Fuzzy
Old
Changes requested
With warnings
← 1 2 3 … 16

Export as