FAQ
Okay, so I have this idea for a module that will allow contrib modules
to have their objects translated. I just did a scan of the modules
available for Drupal 6.x involving translation, and #translateable seems
close but not quite what I'm looking for, but it might be possible to
turn it into what I'm looking for. Here's what I'm thinking:

Many modules work with objects of some sort; particularly my modules.
Because of the complexity of my objects, I've gone a long way to
disengage them from the form. It is not possible to use duplicate,
related objects to do translation, as is often done with nodes, because
a view object does a LOT of stuff and it's very important not to have
duplicates that try to do the same thing. This is also true of Panels.

One thing I can do, is pretty easily identify any string I store as
translateable. This is my proposed API:

Views loads a view. Upon rendering, if the global $language->language
is not the default language, and this module is enabled, Views will
call MODULENAME_translate_object('views', 'view', $view->name) and
do an inline replacement of all strings on the object itself. Views
will also provide a 'translate' link which will lead to a URL provided
by this module to translate that view. It may be possible to do some
fapi integration with ajax translation but that's a 'bonus' feature.
Could be cool, as long as it's not too hard to implement in my already
crazy UI.

/**
* Return an array of translated strings, or NULL if there are no
* translated strings for this object.
*
* @param $module
* The name of the module that owns the object.
* @param $type
* The type of object being translated. Example: 'node', 'view', etc.
* @param $id
* The unique identifier of the object. May be a string!
* @param $language
* The language to translate to. If not specified, use the current
* langauge from global $language.
*/
function MODULENAME_translate_object($module, $type, $id, $language)

/**
* Tell MODULENAME what objects your module has available for
* translation.
*
* @return
* An array of object identifiers. Each one must be unique.
*/
function hook_translateable_objects() {
// example
return array('view');
}

/**
* Tell MODULENAME what strings a particular object has available.
* Because some objects may be dynamic, this is called for every
* unique object id when translation is actively occurring.
*
* @param $type
* The object identifier that corresponds to that used by
* hook_translateable objects
* @param $id
* The unique object ID being translated.
*
* @return
* An array of strings; the key is the string identifier, and
* each value is an array that contains the following:
* - title: The title of the field.
* - description: The description of the field.
* - value: The current value of the field.
*/
function hook_translateable_strings($type, $id) {
// example
return array('view');
}

From the API perspective, that's about all I have to do. I have to do
some extra work to make sure each component of the view provides the
strings properly, but that's not hard.

The translation interface will need to record state information on the
strings, so that it can tell the user if the string has changed since
the last time it was translated, making it easy to highlight what needs
to be updated. It might be nice to provide a way to browse, but I think
it's better to let the module provide that and require the module to
provide a link to the translator; that's less work for this module and
is likely to be much less clumsy.

If someone implements this, I promise Views will use it and will use it
very quickly. If a module like #translateable wants to use something
like this, so much the better; I would really prefer it if an existing
translation module can take on these features, so that we get more
widespread usage. That said, my belief is that any module that Views
uses for translation will see widespread use in the localization
community, and thus, if well maintained, will become a de facto standard
and we can convince other module developers to use it too. I'm willing
to be flexible, too, but Views has special needs; you'll need to cater
to it to get this working, and translating Views is a very important
thing for a truly multi-lingual site. But also, with this API any of my
modules will be easily translateable.

Search Discussions

  • Jose A. Reyero at Apr 26, 2008 at 10:39 am
    Hi Earl,

    I'd invite you to take a look at i18nstrings module (Drupal 6) in i18n
    package, which implementes 'named strings' translation, and some basic
    object support, http://drupal.org/project/i18n (i18nstrings)
    tt('views:viewname:title', "String in default language".......)
    to('views', $view, array('title', 'name', 'footer'....)

    and also some patches on the issue queue, like this one by Gabor, which
    implemented full object localization and was proposed for Drupal 6, no
    luck though, http://drupal.org/node/141461
    dt('view', $view)

    It all is pretty much the same philosophy, using the locale's textgroup
    support for translation interface, that may have its quirks but allows
    easy import/export of translations (I.e. export 'views' translations)
    and a common familiar interface to translate everything, without too
    much work.

    Also if you want to allow translations at some point but don't want to
    do all the work now nor introduce aditional dependencies into views, you
    can use some t-style wrapper for all the views so other modules
    (i18nviews would come next :-) ) can implement it.

    Like views_t($view) before any display operation

    function views_t(&$view) {
    if (function_exists('views_t_implementation') {
    .......
    }
    }

    Or, alternatively, let me know how could I improve i18nstrings module to
    meet your requirements. For what I see below we'd be already almost
    there for views translation.

    Earl Miles wrote:
    Okay, so I have this idea for a module that will allow contrib modules
    to have their objects translated. I just did a scan of the modules
    available for Drupal 6.x involving translation, and #translateable
    seems close but not quite what I'm looking for, but it might be
    possible to turn it into what I'm looking for. Here's what I'm thinking:

    Many modules work with objects of some sort; particularly my modules.
    Because of the complexity of my objects, I've gone a long way to
    disengage them from the form. It is not possible to use duplicate,
    related objects to do translation, as is often done with nodes,
    because a view object does a LOT of stuff and it's very important not
    to have duplicates that try to do the same thing. This is also true of
    Panels.

    One thing I can do, is pretty easily identify any string I store as
    translateable. This is my proposed API:

    Views loads a view. Upon rendering, if the global $language->language
    is not the default language, and this module is enabled, Views will
    call MODULENAME_translate_object('views', 'view', $view->name) and
    do an inline replacement of all strings on the object itself. Views
    will also provide a 'translate' link which will lead to a URL provided
    by this module to translate that view. It may be possible to do some
    fapi integration with ajax translation but that's a 'bonus' feature.
    Could be cool, as long as it's not too hard to implement in my already
    crazy UI.

    /**
    * Return an array of translated strings, or NULL if there are no
    * translated strings for this object.
    *
    * @param $module
    * The name of the module that owns the object.
    * @param $type
    * The type of object being translated. Example: 'node', 'view', etc.
    * @param $id
    * The unique identifier of the object. May be a string!
    * @param $language
    * The language to translate to. If not specified, use the current
    * langauge from global $language.
    */
    function MODULENAME_translate_object($module, $type, $id, $language)

    /**
    * Tell MODULENAME what objects your module has available for
    * translation.
    *
    * @return
    * An array of object identifiers. Each one must be unique.
    */
    function hook_translateable_objects() {
    // example
    return array('view');
    }

    /**
    * Tell MODULENAME what strings a particular object has available.
    * Because some objects may be dynamic, this is called for every
    * unique object id when translation is actively occurring.
    *
    * @param $type
    * The object identifier that corresponds to that used by
    * hook_translateable objects
    * @param $id
    * The unique object ID being translated.
    *
    * @return
    * An array of strings; the key is the string identifier, and
    * each value is an array that contains the following:
    * - title: The title of the field.
    * - description: The description of the field.
    * - value: The current value of the field.
    */
    function hook_translateable_strings($type, $id) {
    // example
    return array('view');
    }

    From the API perspective, that's about all I have to do. I have to do
    some extra work to make sure each component of the view provides the
    strings properly, but that's not hard.

    The translation interface will need to record state information on the
    strings, so that it can tell the user if the string has changed since
    the last time it was translated, making it easy to highlight what
    needs to be updated. It might be nice to provide a way to browse, but
    I think it's better to let the module provide that and require the
    module to provide a link to the translator; that's less work for this
    module and is likely to be much less clumsy.

    If someone implements this, I promise Views will use it and will use
    it very quickly. If a module like #translateable wants to use
    something like this, so much the better; I would really prefer it if
    an existing translation module can take on these features, so that we
    get more widespread usage. That said, my belief is that any module
    that Views uses for translation will see widespread use in the
    localization community, and thus, if well maintained, will become a de
    facto standard and we can convince other module developers to use it
    too. I'm willing to be flexible, too, but Views has special needs;
    you'll need to cater to it to get this working, and translating Views
    is a very important thing for a truly multi-lingual site. But also,
    with this API any of my modules will be easily translateable.
  • Earl Miles at Apr 26, 2008 at 3:27 pm

    Jose A. Reyero wrote:
    Hi Earl,

    I'd invite you to take a look at i18nstrings module (Drupal 6) in i18n
    package, which implementes 'named strings' translation, and some basic
    object support, http://drupal.org/project/i18n (i18nstrings)
    tt('views:viewname:title', "String in default language".......)
    I don't like tt() for Views for three reasons.
    1) Each call to tt() will cause a database access. For a lot of strings
    this is unfortunate. This is one reason that the API I outlined has a
    function that will get all the strings for a given object, which I can
    then go through in that object.
    2) The pluggable nature of Views actually makes me worry that trying to
    use tt() on strings at render time will cause spotty behavior. Whereas
    the system declares what its default options are, so in that same
    function it can also declare which of those options are translatable,
    and once declared the developer of that particular plugin/style/whatever
    never has to worry about it again.
    3) Because of how Views are stored, I don't want the onus of knowing
    when a string has changed to be on Views. Gathering a full list of
    strings for a given object makes, IMO, the management of those strings
    quite easy and the translation module can compare that list to what it
    had before and hilight what has changed on that object for the user.
    Also it makes it much more convenient to translate an entire object at once.
    to('views', $view, array('title', 'name', 'footer'....)
    This doesn't work for Views; Views objects are not flat, and they can
    have plugins which come and go which will drastically change which
    strings are available.
    and also some patches on the issue queue, like this one by Gabor, which
    implemented full object localization and was proposed for Drupal 6, no
    luck though, http://drupal.org/node/141461
    dt('view', $view)
    Reading this makes me realize that I left out setting a type on the
    string, because obviously I'll have some textareas that need to be
    translated as well, and you'll need to know about that. It does look
    like there's some definite similarities with that patch to what I
    propose, but it suffers from the problem I have with to() which that
    Views objects are not flat AND they are very dynamic, so I need a more
    fluid way of telling the system what has changed. It's close, though,
    and I think it could be made to work for me.
    Also if you want to allow translations at some point but don't want to
    do all the work now nor introduce aditional dependencies into views, you
    can use some t-style wrapper for all the views so other modules
    (i18nviews would come next :-) ) can implement it.
    This solution would work but I'm greedy and I want one solution that
    will work for all of my modules, and this one means each module would
    need a companion module.

    So it does look like, perhaps, modifying the dt() patch to be able to
    handle the crazy crazy Views objects. By the way, just to give you an
    idea of what I'm talking about, here is a simplified look at the View
    object:

    $view (views_view object)
    -- displays (array, minimum 1, no maximum)
    -- display (views_display object)
    -- options, style_options, row_options (all arrays of data)
    -- fields/filters/sorts/arguments/relationships (array)
    -- options (guess what? Can also data)
    -- can contain further plugins. With options. Like argument
    validators.

    As you can see, there's a huge amount of nesting. Every view has at
    least 1 display but any useful view has 2 and possibly more. I've got
    real uses for Views with 6 or more displays. I have handler objects that
    can be used to basically recursively compile all the data, and I think
    that's important to this design because it will keep translation code,
    for Views, all in one place. That's one less thing for the developer to
    have to worry about, and trust me, there's plenty for the developer to
    worry about when creating this stuff.
  • Jose A. Reyero at Apr 26, 2008 at 4:36 pm
    Yes I actually share your concerns about queries/performance/full object
    translation. If you read the story of that 'dt' patch you'll see the same.

    More comments below.

    Earl Miles wrote:
    Jose A. Reyero wrote:
    Hi Earl,

    I'd invite you to take a look at i18nstrings module (Drupal 6) in i18n
    package, which implementes 'named strings' translation, and some basic
    object support, http://drupal.org/project/i18n (i18nstrings)
    tt('views:viewname:title', "String in default language".......)
    I don't like tt() for Views for three reasons.
    1) Each call to tt() will cause a database access. For a lot of
    strings this is unfortunate. This is one reason that the API I
    outlined has a function that will get all the strings for a given
    object, which I can then go through in that object.
    2) The pluggable nature of Views actually makes me worry that trying
    to use tt() on strings at render time will cause spotty behavior.
    Whereas the system declares what its default options are, so in that
    same function it can also declare which of those options are
    translatable, and once declared the developer of that particular
    plugin/style/whatever never has to worry about it again.
    3) Because of how Views are stored, I don't want the onus of knowing
    when a string has changed to be on Views. Gathering a full list of
    strings for a given object makes, IMO, the management of those strings
    quite easy and the translation module can compare that list to what it
    had before and hilight what has changed on that object for the user.
    Also it makes it much more convenient to translate an entire object at
    once.
    to('views', $view, array('title', 'name', 'footer'....)
    This doesn't work for Views; Views objects are not flat, and they can
    have plugins which come and go which will drastically change which
    strings are available.
    Agreed. This was just an example of similar features already implemented
    and working so maybe we could build on that.

    Also that module has some in progress (not really working yet but
    coming) support for object prefetching (fetching all 'views:xyz:*'
    strings with a single query...

    The issue is actually more complex than that. While for some objects you
    may want to retrieve all the strings in one hit, for other cases (think
    of a taxonomy autocomplete with localized terms) we may need to fetch
    instead all the translations for a bunch of different objects. So I
    think in principle single string storage, one string per row, is more
    flexible and may fit all these needs.
    and also some patches on the issue queue, like this one by Gabor, which
    implemented full object localization and was proposed for Drupal 6, no
    luck though, http://drupal.org/node/141461
    dt('view', $view)
    Reading this makes me realize that I left out setting a type on the
    string, because obviously I'll have some textareas that need to be
    translated as well, and you'll need to know about that. It does look
    like there's some definite similarities with that patch to what I
    propose, but it suffers from the problem I have with to() which that
    Views objects are not flat AND they are very dynamic, so I need a more
    fluid way of telling the system what has changed. It's close, though,
    and I think it could be made to work for me.
    There was some version of the patch that included also a possible
    callback function to be defined for given 'text groups' (I'll have to
    dig in my dev logs...)
    Also if you want to allow translations at some point but don't want to
    do all the work now nor introduce aditional dependencies into views, you
    can use some t-style wrapper for all the views so other modules
    (i18nviews would come next :-) ) can implement it.
    This solution would work but I'm greedy and I want one solution that
    will work for all of my modules, and this one means each module would
    need a companion module.
    I'm greedier yet and I want one solution that will work for everybody's
    modules :-)

    However I don't think there's anything wrong with an open wrapper that
    allows any other multilingual solution to plug in there, but better if
    it's not 'views' specific. See this patch instead,
    http://drupal.org/node/155047

    As a side note, when dealing with multilingual sites (specially for big
    ones), the main problem for translators is to have one single generic
    UI and workflow to handle *all* translations, so it's really a major
    nightmare if every module or group of modules implements its own
    translation solution. On this sense, all these solutions proposed here
    have the real advantage of using the same translation UI (locale module
    with textgroups), which also can handle export/import of single or all
    text groups, so external tools can be used too.
    So it does look like, perhaps, modifying the dt() patch to be able to
    handle the crazy crazy Views objects. By the way, just to give you an
    idea of what I'm talking about, here is a simplified look at the View
    object:

    $view (views_view object)
    -- displays (array, minimum 1, no maximum)
    -- display (views_display object)
    -- options, style_options, row_options (all arrays of data)
    -- fields/filters/sorts/arguments/relationships (array)
    -- options (guess what? Can also data)
    -- can contain further plugins. With options. Like argument
    validators.

    As you can see, there's a huge amount of nesting. Every view has at
    least 1 display but any useful view has 2 and possibly more. I've got
    real uses for Views with 6 or more displays. I have handler objects
    that can be used to basically recursively compile all the data, and I
    think that's important to this design because it will keep translation
    code, for Views, all in one place. That's one less thing for the
    developer to have to worry about, and trust me, there's plenty for the
    developer to worry about when creating this stuff.
    I guess if you have such 'evil' recursive handler objects ;-) we'd need
    recursive translation handlers too. But also, you know many other people
    may build on your views module and add even more stuff in there. That's
    why I'd leave the door open for translation callbacks that can be
    implemented by other modules.

    About the translation UI you may think also of a specially suited one
    for views, but as I mention above the problem most usually is to have a
    generic one for all translations. Also to keep in mind, translators are
    not necessarily tech savvy people so any UI needing admin access to
    translate strings has some fundamental problem. However, we can also
    build an object UI on top of the single strings one (So the single
    site-admin-developer-I-just-want-my-site-in-two-languages is happy too)

    So I'd really be happy if we could find any good solution that would
    work for all modules. I'd be happier yet if you just provided one I
    could reuse for i18n so I could drop that i18nstrings module :-) Btw,
    there are modules in that package -like i18nstrings- that are spinoff
    candidates so they can be reused by other modules without needing the
    whole i18n stuff. I'm just figuring out how to make it best. So if you
    thought we can build on that for some better solution I'd be happy to
    create a new project for it and add your name to the list.

    Whatever I'm glad you've brought up this issue in the list because we
    badly need some good solution for Drupal 7 string translation and if we
    can have one that is shared and tested by many Drupal 6 modules we may
    be almost there for the next version..

    (Btw, developers still wanted to build *the complete multilingual
    solution* for Drupal 7)

    Cheers,

    Jose
  • Earl Miles at Apr 26, 2008 at 4:55 pm

    Jose A. Reyero wrote:
    Yes I actually share your concerns about queries/performance/full object
    translation. If you read the story of that 'dt' patch you'll see the same.
    Yea, I read the dt() patch after I wrote that part. It definitely
    addressed the performance issues there and they are what I brought up
    and much more.
    I guess if you have such 'evil' recursive handler objects ;-) we'd need
    recursive translation handlers too. But also, you know many other people
    may build on your views module and add even more stuff in there. That's
    why I'd leave the door open for translation callbacks that can be
    implemented by other modules.
    Well, my hope would be that the onus for understanding the depth would
    be on me. With the API I specced out, I just provide you a list of
    strings when you ask for it. The issue is, you can't assume that the
    list of strings you asked for yesterday will be the same list of strings
    you asked for today. One of the reasons that my API has a string
    identifier plus a textual label is that
    'viewname/displayname/field/fieldtype/option/separator' isn't going to
    mean much to the user, but I can translate that into a string which, at
    least in English, will mean something, but also that stuff can all be
    run through t().

    And the idea of organizing the strings is that you *can* group them all
    together, so the textgroup concept, at least, works; I'm not sure about
    the mechanism itself as I'm not familiar with it. As long as it can
    handle strings coming and going arbitrarily then it should work fine.
    About the translation UI you may think also of a specially suited one
    for views, but as I mention above the problem most usually is to have a
    generic one for all translations. Also to keep in mind, translators are
    not necessarily tech savvy people so any UI needing admin access to
    translate strings has some fundamental problem. However, we can also
    build an object UI on top of the single strings one (So the single
    site-admin-developer-I-just-want-my-site-in-two-languages is happy too)
    It's not so much that this is specially suited for Views so much as I'm
    trying to set up something that works for lots and lots of things and is
    able to take into account the flexibility needed. The translator
    shouldn't actually see what's going on; but instead be presented with a
    list of all current, known translatable strings for a given object, and
    highlights for which of them have changed since last time.
  • Daniel F. Kudwien at Apr 26, 2008 at 5:27 pm

    About the translation UI you may think also of a specially
    suited one
    for views, but as I mention above the problem most usually
    is to have
    a generic one for all translations. Also to keep in mind,
    translators
    are not necessarily tech savvy people so any UI needing
    admin access
    to translate strings has some fundamental problem. However, we can
    also build an object UI on top of the single strings one (So the
    single site-admin-developer-I-just-want-my-site-in-two-languages is
    happy too)
    It's not so much that this is specially suited for Views so
    much as I'm trying to set up something that works for lots
    and lots of things and is able to take into account the
    flexibility needed. The translator shouldn't actually see
    what's going on; but instead be presented with a list of all
    current, known translatable strings for a given object, and
    highlights for which of them have changed since last time.
    I have to disagree here. Most of the translators I had to deal with in the
    past always asked first: "What's the context?" or "Where does this appear?"
    Locale's/Translation's interface for adding/editing translations is
    currently built for developers/advanced Drupal users, not translators.
    Developers speak programming languages. I guess only a minority of
    developers can speak additional languages and have also skills of real
    translators.

    To translate a content correctly, translators are more comfortable with the
    approach taken by #translatable. They see the original form and thus, have
    an idea of how all strings and contents of an object relate. #translatable
    stores the translations and does not alter the original data.
  • Earl Miles at Apr 26, 2008 at 5:36 pm

    Daniel F. Kudwien wrote:
    To translate a content correctly, translators are more comfortable with the
    approach taken by #translatable. They see the original form and thus, have
    an idea of how all strings and contents of an object relate. #translatable
    stores the translations and does not alter the original data.
    That's fine and true when it's 1 form, 1 object, but a single view is at
    least 50 forms, most of them with no more than an item or two. Is that
    *really* the translation interface you want? The label I provide can
    lead you to the context, but without promoting stuff to a single level,
    I don't think translating a view directly in the form would be
    considered good UI.
  • Jose A. Reyero at Apr 26, 2008 at 6:34 pm

    Daniel F. Kudwien wrote:
    About the translation UI you may think also of a specially
    suited one
    for views, but as I mention above the problem most usually
    is to have
    a generic one for all translations. Also to keep in mind,
    translators
    are not necessarily tech savvy people so any UI needing
    admin access
    to translate strings has some fundamental problem. However, we can
    also build an object UI on top of the single strings one (So the
    single site-admin-developer-I-just-want-my-site-in-two-languages is
    happy too)
    It's not so much that this is specially suited for Views so
    much as I'm trying to set up something that works for lots
    and lots of things and is able to take into account the
    flexibility needed. The translator shouldn't actually see
    what's going on; but instead be presented with a list of all
    current, known translatable strings for a given object, and
    highlights for which of them have changed since last time.
    I have to disagree here. Most of the translators I had to deal with in the
    past always asked first: "What's the context?" or "Where does this appear?"
    Locale's/Translation's interface for adding/editing translations is
    currently built for developers/advanced Drupal users, not translators.
    Developers speak programming languages. I guess only a minority of
    developers can speak additional languages and have also skills of real
    translators.

    To translate a content correctly, translators are more comfortable with the
    approach taken by #translatable. They see the original form and thus, have
    an idea of how all strings and contents of an object relate. #translatable
    stores the translations and does not alter the original data.

    I think: yes and no.

    Sure people wants to see the context. The context though, for a non tech
    user is a web page on your site and that's it.

    See string on (page) context ---> Translate string

    (If using l10n client, can be done on the same page)

    As oppossed to

    See the string on the site ---> Si what is it? Is it a view?
    ---> So which view is it? ( Find view) -->
    Find string on view -- > (Oh, fuck, not here, it was not
    a view) --> Ask the admin --->
    --> So the admin says it is a block. ---> Wtf is a
    block? -->...... ...
  • Jakob Petsovits at Apr 27, 2008 at 12:15 pm

    On Saturday, 26. April 2008, Jose A. Reyero wrote:
    Daniel F. Kudwien wrote:
    To translate a content correctly, translators are more comfortable with
    the approach taken by #translatable. They see the original form and
    thus, have an idea of how all strings and contents of an object relate.
    #translatable stores the translations and does not alter the original
    data.
    I think: yes and no.
    [snip]

    KDE's i18n() function (same as t() for Drupal) has an optional "context"
    parameter that the developer specifies in order to help the translators out.
    (That context later appears as comment in the .pot file, I believe.)

    Maybe it would be an option to include something like this in some way, in
    order to provide an actual middle ground between "no UI-related context in
    the .pot file" and "no code-related context in the UI string".
  • Gerhard Killesreiter at Apr 27, 2008 at 1:54 pm

    Jakob Petsovits schrieb:
    On Saturday, 26. April 2008, Jose A. Reyero wrote:
    Daniel F. Kudwien wrote:
    To translate a content correctly, translators are more comfortable with
    the approach taken by #translatable. They see the original form and
    thus, have an idea of how all strings and contents of an object relate.
    #translatable stores the translations and does not alter the original
    data.
    I think: yes and no.
    [snip]

    KDE's i18n() function (same as t() for Drupal) has an optional "context"
    parameter that the developer specifies in order to help the translators out.
    (That context later appears as comment in the .pot file, I believe.)

    Maybe it would be an option to include something like this in some way, in
    order to provide an actual middle ground between "no UI-related context in
    the .pot file" and "no code-related context in the UI string".

    Drupal already does something similar if you do not use pre-built PO
    files. The PO comments are filled with the URLs of the places the string
    was encountered first. Not perfect of course, but maybe someting to
    build on.

    Cheers,
    Gerhard
  • Eric-Alexander Schaefer at Apr 27, 2008 at 2:22 pm

    Gerhard Killesreiter schrieb:
    KDE's i18n() function (same as t() for Drupal) has an optional "context"
    parameter that the developer specifies in order to help the translators out.
    (That context later appears as comment in the .pot file, I believe.)

    Maybe it would be an option to include something like this in some way, in
    order to provide an actual middle ground between "no UI-related context in
    the .pot file" and "no code-related context in the UI string".
    Drupal already does something similar if you do not use pre-built PO
    files. The PO comments are filled with the URLs of the places the string
    was encountered first. Not perfect of course, but maybe someting to
    build on.
    I am using a very simple i18n-System in an application, where the
    argument to translate() is not an english text, but a text token. The
    token is itself text an it can contain context. I did that not only for
    easing translation but for creating "namespaces" for text. In most
    application including drupal one word might sometimes be translated
    diffent depending on the context. A simple example is the german word
    "Himmel", which can be translated to "sky" as well as "heaven",
    depending on context. So the tokens could look like this:
    "ADMINISTRATION_SITE_BUILDING_MODULE_CONFIGURATION_MENU_ITEM_CAPTION".
    If you define a token naming policy carefully, the translator knows the
    context just by looking at the token (Thats the caption of the menu item
    pointing to the module configuration section.). With this
    translate-function, every string in every language must be contained in
    a translation file, which could be considered flexible.

    HTH,
    Eric
  • Daniel F. Kudwien at Apr 27, 2008 at 4:35 pm
    Please correct me if I'm wrong, but I thought we were discussing translation
    of user generated contents, not fixed UI strings. By speaking of context, I
    meant the context in hierarchically structured objects; in the given
    use-case - Views.

    Small addition to the approach taken by #translatable: Since translation
    forms *are* the original forms, this system is able to provide the correct
    UI for each translatable content (string/option/file/etc.) without the need
    to re-define how a translation form for a certain object needs to be built.
    IMHO, this is the key for a translation system that needs to be as flexible
    and modular as Drupal is.

    -----Original Message-----
    From: development-bounces at drupal.org
    [mailto:development-bounces at drupal.org] On Behalf Of
    Eric-Alexander Schaefer
    Sent: Sunday, April 27, 2008 4:23 PM
    To: development at drupal.org
    Subject: Re: [development] Seeking help internationalizing
    Views (and Panels and maybe other modules for D6)

    Gerhard Killesreiter schrieb:
    KDE's i18n() function (same as t() for Drupal) has an
    optional "context"
    parameter that the developer specifies in order to help
    the translators out.
    (That context later appears as comment in the .pot file, I
    believe.)
    Maybe it would be an option to include something like this in some
    way, in order to provide an actual middle ground between "no
    UI-related context in the .pot file" and "no code-related
    context in the UI string".
    Drupal already does something similar if you do not use
    pre-built PO
    files. The PO comments are filled with the URLs of the places the
    string was encountered first. Not perfect of course, but maybe
    someting to build on.
    I am using a very simple i18n-System in an application, where
    the argument to translate() is not an english text, but a
    text token. The token is itself text an it can contain
    context. I did that not only for easing translation but for
    creating "namespaces" for text. In most application including
    drupal one word might sometimes be translated diffent
    depending on the context. A simple example is the german word
    "Himmel", which can be translated to "sky" as well as
    "heaven", depending on context. So the tokens could look like this:
    "ADMINISTRATION_SITE_BUILDING_MODULE_CONFIGURATION_MENU_ITEM_CAPTION".
    If you define a token naming policy carefully, the translator
    knows the context just by looking at the token (Thats the
    caption of the menu item pointing to the module configuration
    section.). With this translate-function, every string in
    every language must be contained in a translation file, which
    could be considered flexible.

    HTH,
    Eric

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdevelopment @
categoriesdrupal
postedApr 25, '08 at 10:21p
activeApr 27, '08 at 4:35p
posts12
users6
websitedrupal.org
irc#drupal

People

Translate

site design / logo © 2022 Grokbase