Prepare for language packs from WordPress.org

[pippinsplugins]

Translation packs were just announced for plugins on WordPress.org: https://make.wordpress.org/plugins/2015/09/01/plugin-translations-on-wordpress-org/

This is a really big deal and we should absolutely jump on board.

TLDR: WordPress.org will host all plugin language files and allow users to update their translations anytime a new version is available. EDD will no longer need to maintain or distribute language files.

There are a few things that have to happen in order for language packs to be supported by EDD:

1. WordPress.org has to enable them. This is happening in batches. See post above
2. Our textdomain must be changed to easy-digital-downloads. They require the text domain match the plugin slug. This will break existing translations for anyone that has manually translated text through WPML, qTranslate, Polylang, Say What, etc.
3. Language files must be removed from the plugin.
4. Transifex would no longer be used as all translation would happen by the Polyglots team on WordPress.org. I do not yet know if our Transifex contributors could contribute there.
5. All translations need to be up to date before EDD gets language packs enabled.

@easydigitaldownloads/core-devs Everyone track this please.

@fxbenard Definitely want your input here.

[pippinsplugins]

Post on how to maintain backwards compat for old text domains: http://ibrokemywp.com/2014/12/16/use-your-plugin-or-theme-slug-as-the-textdomain-not-whatever-other-stupid-idea-you-might-have/

[fxbenard]

Integration will be in batch and it could takes months (Otto says). I'm actually expecting a way to integrate TX poke @dovy with WordPress (a kind of TX language pack).

Moving all translators to translate.wp will need you to write an email with the name of each translators you want in each new teams. https://make.wordpress.org/polyglots/handbook/rosetta/theme-plugin-directories/ Good luck with 1000+ translators. It seems pretty complicated to do right now.

We might of course ask all translators explicitly to register there. Personally I will not do it as I support really small plugins in TX that will never had a chance to get translated if they weren't using WP-T teams. And I don't want translators to leave for a tool I think is inappropriate (in his actual state) to provide a good translation tool.

Let's see how it gets integrated, it will still be time to jump in ;)

[pippinsplugins]

Good news is there are a lot of plugins ahead of us, so we should be able to get a better idea of what it will look like before it's our turn.

[fxbenard]

In Slack #wp-i18n Mail start next week, import week after

[pippinsplugins]

We need to do this asap actually. The .org team is moving through plugins quickly. I expect we're just a few weeks away.

[pippinsplugins]

Just got word from @SDavisMedia that he is going to take the first stab at updating text domains today.

[fxbenard]

A post I wrote for MailPoet and what it involves:

• As devs you don't have editors access. No managing access.

• Translations are auto-imported the 1st time the plugin is imported in GP. Better run a grunt tx-pull

• Ask all Transifex translators to move over GP - Kind of rip off for me for what it took years to build.

• Make a special call to the GP team to import for you your contributors like that: https://make.wordpress.org/polyglots/2015/09/17/howdy-polyglots-i-am-the-plugin-author-of/

• When accepted they have to import new translations in case they need them. Means no stats (they overwrite all contributions).

• No shared TMs over projects. Not really important for us. I'm thinking loud about translators having to translate over and over the same strings across projects.

• No project glossary. We start brand new there. Not sure there is one per project by the way.

• Only 100% translations will be included in the language pack (if not en_US will be used).

• In TX no % involved.

• On the other hand you'll get the Powerful language pack + Readme translated.

• You get "badged" translators you don't know anything about EDD translations.

• If we keep translations in TX, no way to tell translators we're there in GP (no banner possible). A grunt GP import is avalaible ;) made by marko.

• We have to change all textdomain to use the plugin slug. @SDavisMedia on it

So as you can see there is no good and bad to move over GP. The project is new, we should be part of it in case of, but on the other hand it ties us to a system that's for me isn't ready yet. There is no good or wrong decision to make, let's participate and we'll see.

To keep you inform, Dovy the Redux's dev is actually working on a TX language pack to overwrite the WP's one + WC class as he want to continue using TX. But to soon to talk about it. it might be a solution also at some point.

[pippinsplugins]

Thank you for all of the feedback @fxbenard

I was playing with translate.wordpress.org yesterday to see exactly how it works for plugins. I have to say that the user experience there is 10x better than Transifex and significantly easier for a new user to figure out. Providing a translation was much, much simpler.

At least that was my experience.

There are definitely downsides, but there is also an upside: nothing about this move prevents someone from using incomplete or custom translation files in the same way they always have.

[fxbenard]

From my point of view GP UX is just hell, poor TM, poor glossary, no comments system, no community spirit, a Poedit online. But that's the way it goes. As i said the project is new. Will see. Only 100% translations will be imported. So if the translations is not 100% and you remove your mo as it's suppose to be then no translations will be used. Needs to hit 100% at some point.

[pippinsplugins]

The UX on translate.wordpress.org isn't the standard GP UX is it? Pretty sure it's customized.

I am really sad about the 100% requirement. That's a major bummer.

[fxbenard]

It's softly optimized then, no changes between my vvv install and GP official. (I'm using it everyday as I'm a maintainer of the French team there, hahaha).

yep the 100% is a bummer, that's why lot's of team are rushing the translations, the quicker, the better :( maybe not.

[pippinsplugins]

I hope they change the 100% requirement. That's so close to almost unattainable it's not even funny.

[cklosowski]

There is some interesting conversation here: https://make.wordpress.org/plugins/2015/09/01/plugin-translations-on-wordpress-org/#comment-42254

Talking about plugins who have non-100% translations. So maybe what we can do is keep working with TransFX and @fxbenard until we get it to 100% on a specific language, and THEN ship it to .org?

[cklosowski]

@SDavisMedia I'm bumping this to 2.5 release, (2.4.6 was a 'let's pay attention to it technique). But please, keep doing your work as soon as possible, we want to be ready whenever they add us to the list.

[SeanTOSCD]

@cklosowski Got it.

[pippinsplugins]

Heads up: we must make a decision on this in the next two-three days as EDD is getting imported into translate.wordpress.org next week. We got the email yesterday.

[pippinsplugins]

Just came across another reason we should opt to do this. From the announcement post:

Eventually, we also plan to give priority to localized plugins in localized directories; e.g., someone searching the Romanian plugin directory will see Romanian plugins prioritized over English-only plugins.

[pippinsplugins]

Good news. The import will happen no matter what (no opt out), but we can decide whether to take advantage of the new system:

[pippinsplugins]

Good news on text domain. Import will still happen if not updated. While we still have to do it for language packs to work, it's not critical that we have it done prior to the import:

[pippinsplugins]

Something to consider. We could build a custom updater to pull language packs from Transifex (I think): https://core.trac.wordpress.org/browser/branches/4.3/src/wp-admin/includes/class-wp-upgrader.php#L1730

[pippinsplugins]

More info on language files that drop below 100% after an update:

[dovy]

You could finish this off: https://github.com/woothemes/woocommerce-language-packs

It works, BUT there are some bugs. I'd love to use it for Redux myself. ;)

[pippinsplugins]

There is a change to our deployment workflow that will need to happen with this.

Currently, when we release a new version, we push to trunk and then immediately tag the release as well in SVN.

In order to help translators translate the plugin pre-release, we should do the following:

1. Do our best to initiate a "string freeze" 2-3 weeks before a release goes out
2. Push the beat version with all updated strings to trunk on SVN
3. Inform translators that it is ready to translate
4. Finish the release and then tag the release once done

[cklosowski]

@pippinsplugins This could be our 'Beta period', while it sits in trunk with the Stable tag set to whatever the current version is. I'm all for that.

[pippinsplugins]

@cklosowski yep.

[pippinsplugins]

There's one big problem: so far there does appear to be any good or even halfway decent way to make translations done through Say What and similar plugins still work after changing the text domain.

[michaelbeil]

What is Say What @pippinsplugins?

[pippinsplugins]

It's a plugin for translating individual strings from @leewillis77 https://wordpress.org/plugins/say-what/

We recommend it a lot in support whenever someone wants to change the text of a button or something similar.

[michaelbeil]

Oh very very nice. Noted.

[pippinsplugins]

Lee has a nice proposal for Say What: https://github.com/leewillis77/say-what/pull/16#issuecomment-143336384

[pippinsplugins]

@fxbenard with the comments above from earlier today, do you have any further feedback for us?

[cklosowski]

The above commit should fix the Say What concerns we have.

@leewillis77 is releasing/has released version 1.6 which adds a feature called domain-aliases allowing us to register an alias of easy-digital-downloads of edd with Say What so that anyone who has created a text change in Say What using edd as the text domain won't need to update anything.

[leewillis77]

No worries - good look with the RSI typing that on every string ;)

[pippinsplugins]

@leewillis77 seriously . . . if only WordPress.org allowed us to register an alias.

[fxbenard]

@pippinsplugins No comments everything seems good. I will rather go with the language pack from TX, as @dovy said, hahaha. And personally I'll prefer managing French on TX even if I'm an official French maintainer on translate.wordpress.

[pippinsplugins]

Thanks @fxbenard!

I suspect the next few months will be a bit rough as everyone adapts to the new system, but I expect it to smooth out and be really nice once the dust has settled.

[chriscct7]

Does this mean that any extensions or custom code that use 'edd' as translated strings will need to be updated to use the new textdomain then

Like for example an extension uses the same string as EDD so it uses 'edd' as the textdomain for the string so the translation pulls from EDD. That will need to change to 'easy-digital-downloads'?

[fxbenard]

Yes! You'll need to use the new textdomain as well.

[pippinsplugins]

@chriscct7 as @fxbenard said, yes. It is also important to note extensions shouldn't ever be doing that as translation files won't pick up on them.

[chriscct7]

If they're exact string matches, they don't need to be picked up by the translation files though, that'd be the whole point of using the 'edd' textdomain.

[pippinsplugins]

@chriscct7 Translation plugins (like qTranslate or Say What) can pick up on them, but WordPress will not translate them.

Pretty positive that is the case but happy (thrilled actually) to be proven wrong.

[fxbenard]

@chriscct7 https://github.com/chriscct7 I think Pippin is right, another plugin will not pick translations from another one.//And the translations will not work. Why we use ´grunt chechtextdomain´

[pippinsplugins]

@chriscct7 Where is the translation coming from if they "don't need to be picked up by the translation files"?

[spencerfinnell]

They definitely don't get picked up by other plugins. Otherwise we just wouldn't use domains.

[samikeijonen]

This is interesting topic, sorry for late reply. 100% requirement feels really strange to me, I don't really get the reason behind that decision. In WordPress.com the limit is 80% for themes if I remember it correctly.

Also, there is a small typo in this function: load_old_textdomaon.

[pippinsplugins]

@samikeijonen The comments in the post on make.wordpress.org have some good explanations for the 100% requirement.

Thanks for catching the typo!

[pippinsplugins]

Closing!

[samikeijonen]

Yeah I read the comments also but not 100% on the same page with them :).

[pippinsplugins]

I don't 100% agree or disagree :)