Make WordPress Core

Opened 17 years ago

Closed 16 years ago

#4260 closed enhancement (wontfix)

Maintaining context of current plugin can simplfy i18n API

Reported by: omry's profile omry Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: I18N Keywords:
Focuses: Cc:


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.

Attachments (1) (1.7 KB) - added by omry 17 years ago.

Download all attachments as: .zip

Change History (5)

17 years ago

#1 @darkdragon
17 years ago

  • Component changed from General to i18n

#2 @omry
16 years ago

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

#3 @darkdragon
16 years ago

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.

#4 @darkdragon
16 years ago

  • Milestone 2.5 deleted
  • Resolution set to wontfix
  • Status changed from new to closed
  • Type changed from defect to enhancement

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!

Note: See TracTickets for help on using tickets.