Field system uses t() incorrectly and inconsistently

Marked #717610: Remove t() calls from $instance['label'] and $instance['description'] as duplicate.

@plach: the focus of this patch is to remove runtime t() of strings. The core and contrib installer functions often use t() when pre-creating user editable things, which is a great way to set up a single foreign language site (but is mostly bad for multilingual setup). I agree we should look into creating and saving the fields with t() if for nothing else, for consistency, not sure it belongs in this patch. This is about avoiding misusing t() and enabling contrib modules to work with a consistent environment so they know what data they work with.

@plach: it is in fact very consistent. When you add a block, a view, a menu item, a contact category or set your anonymous username on your site (or your date format), you are not asked about what language you are doing that in. You can add any number of blocks, views, menu items, contact categories, just like fields, and we don't know the language of those either. Now Drupal core really assumes for most things that you are running a single language environment, where your stuff is in some language. For code it assumes it is English for user provided content (again, blocks, views, menu items, etc), it assumes it is your default language. That the blocks, views, menu items, field properties etc. can be in any language regardless of your site default (eg. you might have admins in different languages creating stuff in parallel, or you might change your mind later to switch to a new default language) is a very live problem. It is not at all confined to field API.

Now the inconsistency here is that of all those things, only field API attempts to use the built-in localization system, which means mostly for our assumptions that it assumes all your fields are set up as English and they will not change (see above for issues when changing user editable strings). There are also possible security issues with using t() for user defined strings. If we use it for default values as Damien suggests, you should note that those might have formats assigned. Now once again, t() is not designed to do this, so it has no idea about those formats. Whether you'll be allowed to edit text that is going to be filtered with that format is then not considered. If you default value for a field is PHP input, you'll be able to translate that on the locale UI (but since that has some XSS validation on the input you'll most likely end up with a WSOD, because your submission might not be valid PHP). Dealing with input formats assigned to custom translatable strings is something that a contrib module needs to provide, there are no provisions in core.

In my point of view letting fields work like all other objects in core that they assume their input is single language and in whatever language we consider the site default is what makes this consistent, not to go on and use a system that was not at all designed with the workflows and security needed for user provided strings. Yes, this removes a partially implemented feature which was well intentioned but did not take the complexities of the issue into account.

Of course we can also try to solve this in core (there is a nice initiative for this in Drupal 8), but what we have in contrib is not satisfactory either. It has different problems that need to be solved. At least we can iterate on that in contrib, and intend to provide better backends for these things. We just sprinted almost all week to provide a better user experience (+ tests, and better integration among other things), but this is a huge problem space. It cannot be solved by slapping a t() to everywhere we think we miss translation.

Now we can postpone this for a couple months until we figure out a better backend in D7 contrib and can port it to D8, but in the meantime field translation will be entirely broke in Drupal 7, and would eventually still need a patch like the one I suggested.

I hope this helps get the point across.

Menu system: for title and descriptions from hook_menu()

This is coming from code, not user input, is it?

Locale: for language names - including those input by the user

The assumption is this "mostly" comes from code. We can obviously skip doing this for consistency.

DB log: for types of watchdog messages

Any module that passes on dynamic data in that field?

Field system, as mentioned, for field types and labels (from hook_field_*_info() - inconsistently) and for field and instance label and description

Yeah...

Menu module: for custom menu names

That should not happen either. i18n_menu has a solution for handling that. This should be eradicated just like fields.

System module: for package names and module descriptions
Theme: for region lists

These all come from .info files (== code). Do you know of any place where they might come from user input?

User: for role names and permission names (inconsistently for permission names)

Yes, this is a problem, and needs to be solved just like fields.

@Damien: re #13, yes, the long term solution is definitely that we should know specifically the language of everything in Drupal. Think "Oh, you are adding a block, tell us the language for this", or "Oh, you are setting up a new field, now which language these field properties are in". Then we can mark all stuff coming from code to be language => en, or let the coder specify otherwise if they write their module in French (yes, that happens too). So then we have a clear inventory of what's in which language. Now if you then have a content type with fields coming from code in English and code in French and user input in French, you can translate only the ones in English to French when they need to be translated to French and only the ones in French to English when it needs to be displayed in English. That assumes we know about the language of everything to fine-grained details. I'm not sure how feasible if that in Drupal 7 but is definitely one of the lines being considered for Drupal 8.

@Damien: that is already not the case. Random Drupal shops around the world will not create their sites in English and translate it to some language just to they can maybe add multilingual support later. Random Drupal shops install Drupal localized instead, they already get their content types, forum vocabulary, anonymous username, etc. localized in their DB when installed and then they add views, panels, rules, etc. in their random language and a couple months later they decide to add a new language to the site.

Even if they start off with multilingual sites right off the gate, for most people it is just way too much to create views, blocks, content types, fields, rules, etc. all in English by default if the site will never be displayed in English. If the languages you need to support are Spanish and Catalan, why the hell would you create every configuration in English? And then still your node created menu items, etc. will not be English. So you need to create all your nodes in English as well first? Not sure these dreams are realistic at all.

It is also the best solution for Drupal 8 at the moment. We might re-introduce t() once/if t() is made aware of (a) text formats / input widget / rendering (b) source language (c) permissions (d) text independent string keys as discussed in details above. I think once we'd introduce all these to t(), its not t() anymore. (Contrib solutions attempt to solve some of these btw, but not yet all of them).

So let's get this committed to Drupal 8 and 7 too.

Following on the request to keep the discussion going (for which I don't think this issue is the best place), I've posted a summary on why t() is evil for non-code text with 9 detailed reasons: http://groups.drupal.org/node/149724 (also cross-posted at http://hojtsy.hu/blog/2011-may-19/drupals-multilingual-problem-why-t-wro... for wider distribution, but commenting is only allowed on the g.do post). I wanted to cover how to not distinguish between user provided and code based text, but the post got too long already...

Doh, sorry for the wrong link...