We're facing a bit of a sticky problem and are looking for ideas around it. It started with SEO for multilingual sites, but is more general than that.
Some module (e.g., Nodewords), create texts in their own tables. These texts are displayed to visitors (page title, meta description and other), so they need to be translated.
We can use drupal_alter to filter these texts and translate them. The only problem is, how to organize the translations.
Translation as strings, via the t() function is technically possible but problematic. The translations will belong to the string's value. This means that when the site title changes, translations are completely lost and cannot be updated.
i18nstrings makes better sense to use, as strings are organized with keys and not only by value. The problem here is that drupal_alter doesn't give us any key, but only the string value.
I wish that there was a central repository for keyed translatable strings in Drupal that modules can use. Something that include the module's name (or context), item name and value. Of course, would be nice if it was translatable.
This way, they wouldn't have to create their own tables and we wouldn't need to hack it.
Any thoughts on how we can solve this properly?
PS - this discussion started when folks who want to use i18n, Translation Management and Nodewords discovered that they can only translate per-node items and not the global settings.
Comments
I wish that there was a
I wrote something for a client that uses CCK based nodes to lookup translations. So a module needs to say "Your IP address is blacklisted", and so does something like:
$msg = strings_get_translated('IP_BLACKLISTED');drupal_set_message($msg);
IP_BLACKLISTED is defined in a CCK node, one node per language using standard translation methods. It works well in practice.
Currently part of the team at https://lastcallmedia.com in a senior Drupal specialist role.
That's a good implementation,
That's a good implementation, but I think that Drupal should have its own mechanism for registering these strings. Otherwise, when everyone comes up with a solution (as we have to do now), there's no standard way.
don't reuse locale table
I like to refer to the current lookup mechanism in D6.
We're facing many issues with the current architecture. Reusing the locale table(s) results in very ugly issues. I understand the idea behind - limiting entities and complexity. But here finally complexity is far more. Things that we tried to avoid (e.g. having own translation submit handlers) finally needed to be implemented. The reuse of columns (e.g. location) with different meaning led to ugly side effects.
Don't reuse things unexpectedly
With highest priority i ask you to implement the lookup in an own table and not reusing a table with partial match. BTW: We're still thinking about doing such a feature branch under D6.
The current structured $context of current lookups in i18n looks like a construct of too high complexity with a bad match to cache / database / ... We should rethink this if we do a new generation.
Missing-API problem
Sure there should be a mechanism in drupal as an API to provide content translation. Anyway since there isn't this WILL lead for D7 to the same situation that modules need to implement wrapper functions - if they don't like to DEPEND on i18n.
To reduce this pain we should carefully release a developer API module that only concentrates on this. Thus modules providing relevant translateability can depend on the API module and don't inherit too much weight.
Difference in definitions
Note also that i18nstrings does something completely different than t():
t translates from neutral (coding=english) language into the ui languages.
i18nstrings translates from the source (content oriented = default language) into the ui language.
This leads to many misunderstandings since i18nstrings is NOT a 1:1 t replacement - it is a different concept.
Generalization needed
While t has in D7 additional options with context, this is not enough for the generalization we need.
Performance / Memory
Note also that the content oriented i18nstrings have potential to contain a huge amount of data (n lines per entity instance supporting i18nstrings), locales are very limited. Thus optimization strategies for locale load is as a static lookup cache into php memory which results in great performance. But for i18nstrings this would be a nightmare: After each added instance memory consumption would grow.
Definition
Finally we're at the point where you started:
I hope we find a way to define APIs carefully enough to make them an accepted international standard. As soon as i have concrete suggestions i'll add them here.
@icanlocalize I agree Drupal
@icanlocalize I agree Drupal is lacking in this area. I would use a module that provided a solution, I don't think there is one. Maybe I'll turn my cck-based solution into a general-purpose module.
As a module author, one of the things that bothers me is that I can't change strings defines in my module without invalidating any existing translations. I might need to fix typing mistakes, improve clarity or make changes to support new/changed features. This all seems very wrong, the concept of string lookup using some kind of ID seems to me the way to go.
Currently part of the team at https://lastcallmedia.com in a senior Drupal specialist role.
Where can I find xliff exporting function?
Thank you so much for the translation_management module!
I work in the language industry and I have long been dreaming about drupal-based translation management system.
Today I check Drupal Groups and find this post.
According to the module page, there is an xliff exporting function for translators.
I didn't find that.
Could you tell me where is this feature?
Thank you so much!
What Miro says
Hi,
sadly I always manage to overlook the important discussions.
IMHO Miro pointed at the mayor things. To me the biggest thing is the missing API. Give a standard that the contrib devs can stick to.
--
comm-press |