Maintaining context of current plugin can simplfy i18n API

[omry]

Following a discussion in the mailing list regarding improving the translation functions so that plugin authors will be able to provide their own translation files, which will be loaded automatically and available through the standard () and _e() functions without specifying a domain, I wrote a small prototype that demonstrate how it can be done.

the full thread is ​here, and the updated prototype (with stack support) is attached to the ticket.

before looking at the code, its suggested to read the mailing list thread.

[omry]

thread can also be read ​here (easier to read).

[darkdragon]

Reading over the discussion, I've come to the conclusion that the arguments made in the discussion are correct. Plugin authors should be responsible for maintaining l10n context. The API needs to maintain its optimized status and an decrease in performance such as this ticket could slow WordPress down.

I'm not going to close this ticket out, because I haven't looked at the code, nor did any profiling. I just don't think that the API for plugins and themes is that difficult, that it justifies something like this.

[darkdragon]

The i18n API has been simplified enough. While the code might work, in the context of the code it is contained in. Placing it in the code of WordPress might not do so well. I don't think the stack method implementation is the best solution.

Furthermore the means to get this to work correctly, would further slow down WordPress. I think it is a nice idea, but production wise, unless there is a better implementation. I think I agree that better documentation should and will be written to further educate plugin authors on how to use the current API implementation.

The current i18n API implementation isn't that difficult and I'll be willing to write those tutorials today and tomorrow.

The best fix for this, is really education, which causes no performance overhead and testing.

Thanks for providing a proof a concept!