Exports: t'ify view templates by default

There isn't a good way for the export system to know which strings should be encased with t() and which should not. I haven't come up with a way to do this, and I've tried.

The best I can think is that there needs to be some smarts; plugins have to mark everything that might be translateable, and then the export system has to acknowledge all of those smarts, which is actually the harder part.

This kind of work needs to be done eventually, anyway, when there is some kind of system that will allow us to do translation of views that are in the database, but currently the system I need does not exist.

Ok, so this is kind of whacky, but I just refactored Views so that it actually knows what's translatable and what's not.

Instead of putting the t() in the export, it actually now runs stuff through t() on load, so you get automatic inline translation of Views; I spoke with Goba and while this is not an ideal solution, it basically works like the menu system does. Unfortunately this means there is no way to automatically extract default view values, but I guess the menu system doesn't do that? i'm not entirely sure how that's supposed to work.

Before I delve too deeply into this...how does POTX work for menu strings?

The short answer is: I didn't rewrite the export, because it'll be a fairly significant amount of code to do. I may end up doing that, but it will have an impact on modules and I'm trying to minimize how much this impacts the API (I am in beta, after all, changes to the API are something I try to avoid).

Second, I'm concerned about inconsistent string handling between default (in code) and in database views. If the export has strings run through t(), then they should *not* be translated on the fly but instead should skip translation, and that requires extra code to deal with there, too.

If you export t() with the views exports, then when you import it, the translated texts will be imported, since the eval()-ed code will be imported, which runs the t(), right? So exporting t() in the code is not an option.

The menu code indeed is recognized by potx because there are simple rules to follow there. Potx parses the module source code and recognizes the title and description fields or menu items based on simple patterns.

Exported views could just as well have these simple patterns defined. But potx has two running modes. One is static code analysis outside of a running Drupal instance. This would not be views compatible at all, unless all views are exported to code at the time of parsing. The drupal runtime integrated potx running mode (when potx is used as a Drupal module) has access to the views API, so it could request exports of views, and parse that code (since potx is better in parsing code then examining database tables for whatnot - although we could look in tables just as well). But in this case, it might make more sense to just add a hook to potx so it could ask other modules to provide a list of translatable strings.

At the end, again, this is all something the locale subsystem in Drupal was *not* designed for, so we are piggy backing a system used for static string translation. However, there is no better way I can offer to Earl without him writing a translation system on his own.

Goba: Tell me what I need to do to tell potx about View strings and I'll put it in.

Again, potx is a static code analysis tool, so if you intend to provide the t() wrappers in the exported views for the code analysis, then that's what you can do to let potx know about the strings. Then potx would need to parse the exported views. And the views import should remove the t() wrapper before evaluating the code as Hass suggests. Since potx is a static code analyzer tool, there is no other way but to generate static code for it right now (unless we advance potx to some other direction as well, eg. through some new hooks).

There's a solution to this problem in the gettext() world that we can borrow: to have a "no op" version of t(), which would return its argument as-is. We could name it nt(). POTX should be extended to treat it as if it were t() (btw, it already does this for st()).

$names = array(nt('merlin'), nt('hass'), nt('gabor'), nt('mooffie'));
foreach ($names as $name) {
  print t($name) ."\n";
}

// In the gettext() world there's customarily _("something"), and
// there's its no-op version N_("something").

printf("%s\n", _("Hello"));

const char *names[] = { N_("merlin"), N_("hass"), N_("gabor"), NULL };

int i = 0;
while (names[i]) {
  print("%s\n", _(names[i]));
  i++;
}

The python documentation nicknames this "deferred translation", but I don't see this term used elsewhere.

t() becomes a no op if the current language is english (assuming source string is english) so perhaps this could be faked by Views setting global $language to english or neutral or somesuch before it processes the default views. just a (hackish?) thought.

But, Moshe, why a hack? Why not have an official no-op?

Other scripting languages too make use of a no-op version for their t().

Not having a no-op is the reason POTX have quite a bit of "special handling" code.

One may argue: "Having an nt() will confuse programmers, becaue they'll have to stop and think whether to wrap their string in t() or nt()."

This argument isn't valid: They alreay have to think: Whether to wrap their string in t() or not to wrap it at all (e.g. in hook_manu, watchdog, etc.).

Perhaps we should file a 'feature request'. Is somebody here interested enough to open one?

You are right Moofie. We could probably get a new function like nt() into D6 since it won't break anything.

If Goba were to support it, maybe. But the ramifications of doing so seem quite large. Also then someone would have to write the complex export code I managed to avoid to identify every string marked translatable. =)

Would be nice to do *something* here. I'm not really one to decide what.

I think the step here is to provide proper integration for potx. In theory it should not be too difficult to write code that looks for a module's default views and scans them for translatable strings and provides them to potx. I'm going to leave that to volunteers, though.

Because then we lose database translation handling.

Closing this issue in favor of the current issue about creating translation plugins, which will solve this.