Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Translate_Adapter_Ini Component Proposal

Proposed Component Name Zend_Translate_Adapter_Ini
Developer Notes
Revision 1.0 - 26 September 2007: New source integration for Zend_Translate. (wiki revision: 8)

Table of Contents

1. Overview

Zend_Translate_Adapter_Ini is an additional source integration for the core component Zend_Translate.

2. References

  • none

3. Component Requirements, Constraints, and Acceptance Criteria

  • Zend_Translate_Adapter_Ini is an additional source format for Zend_Translate
  • It will integrate the useage of Ini files for translation into the Zend_Framework
  • This component can not create new Ini files, it only can parse them for framework integration

4. Dependencies on Other Framework Components

  • Zend_Translate_Abstract
  • Zend_Exception

5. Theory of Operation

This component integrates Ini source files into the Zend_Framework.
It derives from Zend_Translate_Abstract and can be used by Zend_Translate to serve source files for translation.

Ini Files are simple from the point of creation.
They can be processed by customers with a simple text editor.

6. Milestones / Tasks

  • Milestone 1: [DONE] proposal written
  • Milestone 2: [DONE] Zend_Translate - Thomas Weidner
  • Milestone 3: [DONE] Code class based on Zend_Translate_Abstract
  • Milestone 4: [DONE] Unit tests and debugging
  • Milestone 5: [DONE] Documentation done

7. Class Index

  • Zend_Translate_Adapter_Ini

8. Use Cases

Use of translation - HTTP_ACCEPT_LANGUAGE: de_AT

9. Class Skeletons

Example Ini File:



Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Dec 16, 2007

    <p>Would it make sense to have an adapter for Zend_Config objects? That way we could just pick up any format that Zend_Config supports.</p>

    1. Dec 16, 2007

      <p>I don't think that this would make sense.</p>

      <p>Config files are completly different from translation files.<br />
      Even if they use the same suffix we have to keep in mind that the purpose of configuration and translation is completly different.</p>

      <p>Configuration should not be thrown together with translation within the same file.<br />
      Translations are normally bigger files than configs. And we would integrate the overhead of Zend_Config and couple Zend_Translation to Zend_Config.</p>

      <p>Btw: The implementation is ready for core, see the attached file, if this proposal get's approved.</p>

      1. Jan 02, 2008

        <p>I respectfully disagree. The syntax of the files is the same, even though the end purpose may not be. I'd even argue that there's a Zend_Config-friendly INI syntax that could work with Zend_Translate:</p>

        <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
        <translation-key>.source = "something to translate"
        <translation-key>.translation.en = "..."; English translation
        <translation-key> = "..."; German translation

        <p>or in Zend_Config XML:</p>

        <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
        <?xml version="1.0">
        <source>something to translate</source>

        <p>or, conversely, a Zend_Config array:</p>

        <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
        $translations = array(
        'translation-key' => array(
        'source' => 'something to translate',
        'translation' => array(
        'en' => '...',
        'de' => '...',
        return $translations;

        <p>These may not be the forms you're promoting for Zend_Translate, but they are forms that would look reasonably familiar to most ZF developers (I'm not saying the above is written in stone, either; just providing an alternate format for discussion). Support for Zend_Config could be easily added by adding Zend_Config awareness to addTranslation() (if the first argument is a Zend_Config object, process the config into the internal Zend_Translate format). An INI adapter could then simply accept an INI file, load it into a Zend_Config, and parse it using the same internal Zend_Translate_Adapter method for dealing with Zend_Config files; a more general Zend_Translate_Config adapter could be used for passing arbitrary Zend_Config objects as translation adapters.</p>

        <p>Please let me know if this sounds reasonable, and if not, what objections you have and the background for them (and no, Zend_Config overhead doesn't count – it's minimal and reasonable <ac:emoticon ac:name="wink" /> ).</p>

        1. Jan 06, 2008

          <p>The INI adapter was proposed because of several OLD files/customers using this syntax. For most I18N issues this one is in my eyes quite useless.</p>

          <p>So here are my problems with what you've mentioned:</p>

          <p>The translation would not work the way you wrote. Translations are always streight key/value pairs. A sub-array syntax as proposed by you within the shown examples would not work as expected. Only special xml formats can include several languages within the same file but this includes problems with not translated strings and misspelled languages. I would not want to implement problems by such a syntax if it can be avoided.</p>

          <p>A format which is hand-crafted like ini or array must be as simple as possible if you want to use it within I18N. Usability should be as high as possible.</p>

          <p>A "Zend_Translate_Adapter_Config" would seems to change some configuration setting within Zend_Translate_Adapter instead of accepting translation files.</p>

          <p>This would also negotate the existing array and xml adapters.</p>

          <p>And it would hard-couple Zend_Translate to Zend_Config. Actually this coupling is not needed so Zend_Translate can be used without Zend_Config. This was also the reason why I added php's own ini-parsing function instead of Zend_Config's. This way Zend_Translate can be used without Zend_Config.</p>

          <p>I thought that simplicity should be done where applicable, and parsing ini files is really simple with php. <ac:emoticon ac:name="wink" /></p>

          1. May 09, 2008

            <p>Actually, there's also a technical argument behind not using Zend_Config for this: message keys could potentially contain characters that are invalid for PHP variable names, which would make them raise exceptions with Zend_Config. So, I'll have to agree with you in the end. <ac:emoticon ac:name="smile" /></p>

            1. May 21, 2008

              <p>Then only waiting or approvement as class is already coded... should one of the quickest implementations... from approvement to core in just a few days. <ac:emoticon ac:name="smile" /></p>

  2. Jun 02, 2008

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Comments</ac:parameter><ac:rich-text-body>
    <p>This proposal has been accepted for development in the standard incubator as-is.</p></ac:rich-text-body></ac:macro>

    1. Jun 18, 2008

      <p>The component has been completly integrated into incubator.<br />
      Unittests and Documentation are finished.</p>

      <p>The component itself is ready for being cored.</p>