One very good feature will be to keep tables head (and also tables elements if possible) translatable, adding t() function.

It's possible?

Comments

pobster’s picture

Hmmm... Not sure I understand? Table heads and elements translatable? Do you mean for css? So tables are styled differently depending on the locale? Uhhh... Really? That can't be it? Could you explain a little more clearly? I'm all for new functionality but please don't expect to see anything new in the 1.x branch.

Pobster

pobster’s picture

Priority: Critical » Minor

Critical??? I don't think so - I'm not sure a feature request can be critical?!!!

Pobster

d.sibaud’s picture

I can explain better: the need is to have th and td content fields translatable through the 'translation interface', this to have less tables with same data for multilanguage sites and to give final users the ease to update only few fields in few tables.

ex:

(english)
| Rooms | Description | Price | ....
| data | data(en) | data | ...

(italian)
| Camere | Descrizione | Prezzo | ....
| data | data(it) | data | ...

It's a critical feature request, because it make so hard for the final user to manage too much tables with same data for different languages.
But if you want to keep it 'minor' is not a problem, for my needs is critical :-)

pobster’s picture

Meh critical is only really reserved for bugs - I get bothered by Drupal emails telling me all about my critical issues because obviously if a module is suffering from a critical bug, then it needs sorting asap. Feature requests on the other hand don't really need popping into my inbox every day!... You see where I'm going with this! ;o)

Hmmm I do see, and tbh - it is a nice idea... I'm just concerned about a couple of things. Drupal doesn't really handle translating user content that well (imho) I mean for static text in modules it's great. But for UGC I think it lacks elegance... Completely separate nodes have to be created to hold translations. Tablemanager 1.x only allows insertion via Drupal filters so this isn't a problem - but how on earth would the UI cope with using the same table across two locales? I can't think how it could possibly be managed? It would have to be fairly complicated and wouldn't save the end user any time as they'd still have to update the table in several places? It'd end up being more or less the same clunkiness as having two (or more) tables to manage anyway?

On a different perspective, if you were only concerned about the header and not the content of the table - you could define translated mappings. This would be fairly easy to implement but as I mentioned before I'd only be interested in putting it in the 2.x branch... And Tablemanager is very low on my list of priorities at the moment. I wouldn't even really need to change much as a separate table holds the header information - I could easily just add a locale column in there.

Pobster

pobster’s picture

Hmmm that's a lot of blah... To cut down the above, could you just explain how you envisage the user experience to be? I just can't imagine it'd be any simpler than managing two (or more) tables.

Feel free to knock up a jpg in photoshop or whatnot?

Pobster

d.sibaud’s picture

thanks for your attention, pardon for using the wrong priority for the feature request, next time I'll be more careful :-)

You're right on the Drupal language managing analysis and, on the other hand, create and storing a whole table (th and td) for each language and in the same time ask the user to insert N times the same value but in different languages is equivalent to let him/her create a new tablesmanager's table and furthermore it's not easy to give a clear UI to input the multilangual data.

So, taking your time, I need it bad, but I well understand that you have your priorities to give, if you can manage to make only the headers tranlastable, adding a local column in there as you said, you can easily became my superDrupalHeroe ;-)

Thanks again and good work.

pobster’s picture

Issue summary: View changes
Status: Active » Closed (outdated)

Closing as D6.x is now unsupported.