- #I CAN SEE YOUR FACE I CAN HEAR YOUR VOICE UPDATE#
- #I CAN SEE YOUR FACE I CAN HEAR YOUR VOICE UPGRADE#
- #I CAN SEE YOUR FACE I CAN HEAR YOUR VOICE PRO#
This allows to approve strings and release translations immediately (if > 95% of strings are ready). Which means I ask for PTE rights in Slack and (probably) get it in some days. Personally, I’m now building relations with local WP Team and its Locale Manager. The good news is that anyone can request PTE status for a certain project. And if your project has no editor for your locale, all translated strings can hang in “Waiting” status for years. All strings should be approved by PTE (Project Translation Editor) or global editors.
#I CAN SEE YOUR FACE I CAN HEAR YOUR VOICE UPDATE#
This triggers the update system, all users get a notification “New translation for %plugin_name% is available” in their dashboards.īut there is also the reverse side of the coin. mo when a certain % of strings gets translated (approved). I haven’t configured Glotpress serverside yet myself, but if I understand it right, Glotpress manages the local packages and rebuilds.
#I CAN SEE YOUR FACE I CAN HEAR YOUR VOICE UPGRADE#
And all the updates are delivered to the end users automatically through the WP upgrade system. It’s deeply integrated with plugin/theme directories (which allows authors to request translations for meta data - readme files etc.), supports user roles and many other things. This is probably the best tool ever for collaborative translation within WP ecosystem. GlotPress native interface is used for projects hosted on and similar. This depends on a project type and environment.
#I CAN SEE YOUR FACE I CAN HEAR YOUR VOICE PRO#
I’ve used Poedior Pro version some time ago for that, but now I opt out in favor of Free version + command line tools. This guarantees that there are no lost or outdated strings from previous builds.
It also extracts some plugin meta (author, version, link, description etc.) and includes into translation files. Assuming text-domain is a proper value of the “Text Domain” in a plugin meta and is used in all localized strings. This looks for localized strings in a current directory and its subdirectories, checks if they belong to the common text domain and puts them into a valid. languages/text-domain.pot -domain="text-domain". Typically I switch to a plugin folder and run: pot file directly from the command line which requires WP-CLI or gettext utilities (see below). mo files when saving a translation and can update strings from the source/pot files.įree and flexible is making a. Any version of the Poedit (even free) (re)creates. It parses the code files and extracts localized strings (GNU gettext, twig templates) into a. Paid and lazy is Poedit PRO, which has a special option “Translate Wordpress theme or plug-in”. There are two typical ways to generate a. plugin uses a single text-domain (see notes in the Issues section).plugin source files are properly localized, translatable strings are wrapped with _ (), e(), esc_html() or esc_html_e().
Hi try to give a detailed answer (maybe someone could use it as a kinda draft for a tutorial).
0 kommentar(er)
