Zend Framework

Zend_Translate_Adapter_Xliff: use own attribut trans-unit id as array keys for $this->_translate instead of source strings

Details

  • Type: Improvement Improvement
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.9.5
  • Fix Version/s: 1.10.0
  • Component/s: Zend_Translate
  • Labels:
    None

Description

I use Zend_Translate for a multilingual website. Therefor I would like to use the adapter "Zend_Translate_Adapter_Xliff".
A translation file is structured as follows:
------------------------------------------------------------------
<?xml version="1.0" ?>
<xliff version='1.1' xmlns='urn:oasis:names:tc:xliff:document:1.1'>
<file original='en.xml' source-language='de' target-language='en' datatype='plaintext'>
<body>
<trans-unit id='menu_home'>
<source>Startseite</source>
<target>Home</target>
</trans-unit>
<trans-unit id='menu_produkte'>
<source>Produkte</source>
<target>Products</target>
</trans-unit>
</body>
</file>
</xliff>
------------------------------------------------------------------

I would prefer to use the trans-unit id(s) as array key(s) for the translation instead of the source strings. This method has some advantages. As example when changing the translations. You don't have to:

  • update content within the translation file
  • update content within source file
  • update source-entry within each translation file (such as 'fr', 'es', 'de', 'cn' ...)
  • look within all your php scripts where you call "$this->translate()" to translate this content

The use of the "Zend_Translate_Adapter_Xliff" will be terrible if a source such as the complete Terms & Conditions are provided. In a view-script you will translate this full text like this way:

$this->translate('1. These general terms and conditions apply to each and every booking made by any person or entity (hereinafter referred to as the "CLIENT") with Diep in die Berg (hereinafter referred to as the "PROPRIETOR") for any function, occasion or utilization of the facilities of the PROPRIETOR.').

And this is for example only the first paragraph!!!

If no optional possibility will be created to use the trans-unit id, it would be sufficient to declare the methods "_startElement" and "_endElement" as protected to own the possibility to extend them.

And yes, I read this issue / improvement: http://framework.zend.com/issues/browse/ZF-4114
But something must happen please!

Activity

Hide
Thomas Weidner added a comment -

Transunit ID is an optional element so we can not use it because it's optional.

Additionally you forgot the negs of such an change.

  • when something is not translated your user would get cryptic keys
  • when something changes in your source the xliff tool would not be aware of the change as there would be no connex between source and target
  • within your source there would be no way for the author (which could be another person than the coder) to know what is meant without looking into the translation file
Show
Thomas Weidner added a comment - Transunit ID is an optional element so we can not use it because it's optional. Additionally you forgot the negs of such an change.
  • when something is not translated your user would get cryptic keys
  • when something changes in your source the xliff tool would not be aware of the change as there would be no connex between source and target
  • within your source there would be no way for the author (which could be another person than the coder) to know what is meant without looking into the translation file
Hide
Sven added a comment -

"Transunit ID is an optional element so we can not use it because it's optional."

Transunit ID is required in XLIFF 1.1 and 1.2 Specification:
"The required id attribute is used to identify the <trans-unit> within the file".
http://www.oasis-open.org/committees/xliff/documents/cs-xliff-core-1.1-20031031.htm#trans-unit
http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#trans-unit

Show
Sven added a comment - "Transunit ID is an optional element so we can not use it because it's optional." Transunit ID is required in XLIFF 1.1 and 1.2 Specification: "The required id attribute is used to identify the <trans-unit> within the file". http://www.oasis-open.org/committees/xliff/documents/cs-xliff-core-1.1-20031031.htm#trans-unit http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#trans-unit
Hide
Thomas Weidner added a comment -

This does not change what I said before.

When you are in need of short translations, also within your code like you wrote before you should use the mentioned "id" as source.

Changing the behaviour of this single adapter to something which does not conform how translation is done in the rest of this framework is actually no option.

Show
Thomas Weidner added a comment - This does not change what I said before. When you are in need of short translations, also within your code like you wrote before you should use the mentioned "id" as source. Changing the behaviour of this single adapter to something which does not conform how translation is done in the rest of this framework is actually no option.
Hide
Sven added a comment -

It's a pity that it is not possible to implement an optional paramater (for reasons of backward compatibility) to instruct the adapter to select the Transunit ID and not the source string as array key.

Show
Sven added a comment - It's a pity that it is not possible to implement an optional paramater (for reasons of backward compatibility) to instruct the adapter to select the Transunit ID and not the source string as array key.
Hide
Thomas Weidner added a comment -

No for this feature.

It would change behaviour in relation to all other adapters. Additionally it would add the above described problems.

When you are in need of a "special" version you can still simply extend the related adapter and create your own specialized version.

Show
Thomas Weidner added a comment - No for this feature. It would change behaviour in relation to all other adapters. Additionally it would add the above described problems. When you are in need of a "special" version you can still simply extend the related adapter and create your own specialized version.
Hide
Thomas Weidner added a comment -

Reopening

Compared with TMX format which are both from LISA.
Based on TMX I agree to add such an option for XLIFF.

Show
Thomas Weidner added a comment - Reopening Compared with TMX format which are both from LISA. Based on TMX I agree to add such an option for XLIFF.
Hide
Thomas Weidner added a comment -

Based on the xliff standard the usage was fixed.
Integrated with r19457.

Show
Thomas Weidner added a comment - Based on the xliff standard the usage was fixed. Integrated with r19457.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: