CVS edit link for ricardodpsx

Translatable Field or Translation By Field is an alternative to the default translation architecture of Drupal “Translation by node”, that creates an entire new node when you translate the source. CTF allows you to translate only the fields you need, avoiding synchronization of common values and duplication of data, problems with node-references on translated nodes etc.

I made this module, based on the Drupal issue http://drupal.org/node/367595, because I had a LOT of problems with this thing while I was working in an International site project. The solution is similar to http://drupal.org/node/367603 but with a different strategy.

CTF translation logic is almost transparent to the entire system, causing most of the contributed modules can work without be aware of translation issues. I have proved with “Views”, “Node Reference” and other popular modules and CTF works well.

For a working sample see:
http://webxaonline.com/ctf/

You can also try the module using this authentication data:
For login as admin: admin/123456
For login as editor: editor/123456

Please don't write bad words there :P

CommentFileSizeAuthor
#1 ctf.zip24.05 KBricardodpsx

Comments

ricardodpsx’s picture

ricardodpsx commented
Status: Postponed (maintainer needs more info) » Needs review
StatusFileSize
new ctf.zip24.05 KB
sun’s picture

sun
Primary language German
Location Karlsruhe
commented

Only subscribing for now.

ddorian’s picture

ddorian commented

any news on this?

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Needs review » Needs work
  1. Doesn't follow Drupal's coding standards. See http://drupal.org/coding-standards
  2. The code only seems to integrate with various forms, but not with CCK's CRUD API functions.
  3. Major: This module should not alter the global database prefix. That's a fundamental wrong usage of $db_prefix.
  4. Major: In several queries, values of variables are used without escaping. You should use the database API functions with usual replacement tokens.
  5. The code relies on database views, which may not be supported on all hosts/servers. The documentation should clarify this upfront.
  6. Major: Improper usage of Form API's internal functions. You should either use the regular functions (drupal_get_form()) or make yourself familiar with the innards of Form API.
  7. Improper use of t(). See http://api.drupal.org/api/function/t/6
  8. Major: Some user-provided values are output without sanitization. See http://drupal.org/writing-secure-code

    One code comment in ctf_where_is_this_field() asks whether to use check_plain() "here" or in the calling function - but neither of both uses it.

  9. hook_uninstall() should use variable_del(), not variable_set().

All major issues listed above need to be addressed.

Not belonging to this review, just a personal note: This approach has hard, technical limitations and therefore won't live long. I've currently no time to explain this in detail, but I wanted at least mention it. However, especially when considering our current efforts for D7 and beyond, it would make much more sense to join forces on the future-proof solution. Again, this paragraph won't hold off this application.

ricardodpsx’s picture

ricardodpsx commented

thank you very much for your recommendations. I'm not Drupal expert but I would like to learn all that I need to be a pro.

I created this module because I had hard Problems with translation by node architecture, so this module save me for a lot of work and duplication of data. I know is not the Ideal solution, but is working for me, anyway I will follow your recommendations, but there is a problem with one of them:

I think I can solve almost all the "Major" tasks you told me, but not one: "usage $db_prefix" becouse that is the base of the trick, I dynamically change the prefixes to simulate the translation by field, this way if the language is set to spanish, drupal retrieve from table 'es_node' instead of 'node', 'es_node' is a view that has the same structure as node but retrieve the title field for another table, the same thing happend withr cck tables and node_revisions tables.

So, that is an impassable obstacle? there is another way to change the name of some tables dynamically for all the core during queries? Is imposible to use $db_prefix variable without cause side-effects?, Currently I don't have Idea of how to do that without modify dynamically $db_prefix, I would appreciate any clue you can give me.

Another question:
There will be early a Drupal 6 patch for translatable-field, compatible with views, cck and common modules?

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

$db_prefix is used exclusively for Drupal multi-site setups. With the approach of this module, users cannot use custom database prefixes.

While that would just be a documentation issue, I fear that this (ab)usage of $db_prefix can lead to security issues. I'm not sure, but this needs to be ensured.

--

Translatable fields is a unique new feature in Drupal 7 core, which required substantial changes to the entire field system. D7's field system speaks languages now, or in other words: A language is required for the entire workflow of field values. Each and every field value has a language. The "node translation" approach is basically dead in D7.

However, while D7 now requires a language for every field (value), it does not ship with a built-in field translation UI, as we were running out of time. We (the Internationalization team) are implementing this over in http://drupal.org/project/translation - of course, you are welcome to join that effort.

This fundamental language support cannot be backported to D6, as you'd have to rewrite Node, CCK, Views, and any other module that tries to work with fields.

Again, personal note unrelated to this application: Since D7 is getting more and more stable, it would make zero sense to try to implement yet another field translation hack for D6. Any approach that does not change the core structure of fields to always have, understand, and support a language won't work out. D7 contains exactly that core change now. And since fields are used for plenty of things in D7 (not just nodes), the new translatable fields allow you to translate much more content.

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented
Status: Needs work » Closed (won't fix)

There have not been replies in the past week; I am marking this application as won't fix.