We are about to let the user be able to translate things like "site footer", "site slogan", "user welcome mail" and so on, all stored in variables.
Thanks, that helps. I misunderstood what Dries meant by footer, but isn't this possible simply by passing the result of variable_get through t()? Or am I missing something? I'm pretty unfamiliar with translate API's. I still think the separation is good, but that's my own opinion. I still maintain a nervousness around the results of variable_get perhaps being translated without my explicitly asking for it in code. The choice of the "default" behavior will be important. Or the work involved in setting up arrays and hooks for every setting I need to define and tell drupal wether its translatable. What about providing a variable_get_t call that would automatically pass this through the new translation API... or am I oversimplifying here. Not trying to be difficult, but just trying to understand better the impact on module developers.
We are about to propose a basic object based translation system, watch the issue queue.
I'll certainly do so.... but doesn't this mean that we're pursuing a generic solution to translations that could be applied here? Is there an easy way to watch the issue queue for just this
1. Seems elegantly solvable using DEFINE and using the normal module namespace conventions. It's also the way most programming languages deal with this simple problem. define('EXAMPLEMODULE_MYVALUE','www.example.com');
I've read every post on this topic (hours of reading, but luckily was sick and had spare time to kill) and perhaps again have misunderstood. The scope of this discussion has crept a great deal. If in the end, the patch goes in with the item array syntax, perhaps we could write some helper functions that would make something close to the "define" syntax available for module developers. I'll volunteer to write the functions when we get there :).