about the worst way to tackle this. What happens when you need to add
a language? You would have to create a new models!
If you are planning on having a category hierarchy, then just make
your top level the languages:-
en
category 1
category 2
de
Kategorie 3
Kategorie 4
Paul
On 27 Jan 2009, at 14:42, Moritz Mertinkat wrote:
>> But the locale data are not only translataion of the name!
>
> Which then is option 2)...
>
> You put your categories for CZ as well as for EN in your category
> table,
> distinguished by category_language = (en|cz). category_name might be
> a token
> for Zend_Translate.
>
> Your entries might look like these:
>
> (category_id, category_parent_id, category_name, category_language)
>
> (1, 0, "food", "en")
> (2, 1, "cheese", "en")
> (3, 1, "ham", "en")
>
> (4, 0, "special_english_food", "en")
> (5, 1, "fish_chips", "en")
>
> (6, 0, "food", "cz")
> (7, 6, "cheese", "cz")
> (8, 6, "ham", "cz")
>
>
> Thus you could display "special_english_food" only for en locale
> plus you
> could use Zend_Translate for more general items like "food" or
> "cheese".
>
> But it's up to you; just a suggestion :)
>
>
> Václav Vaník schrieb:
>>
>>
>> Moritz Mertinkat-3 wrote:
>>> Actually there are only these possibilities:
>>>
>>> 1) you have exactly the same categories (different naming in
>>> different
>>> languages of course), which are always displayed in the same way
>>> => use Zend_Translate (simple + stupid translation case)
>>>
>>> 2) different subsets of categories are displayed in relation to the
>>> language
>>> (6 for EN, 4 for CZ,...), but the meaning is identical
>>> => use Zend_Translate
>>>
>>> 3) your categories differ in meaning (language specific content)
>>> => Zend_Translate could be used, but it's easier to store the
>>> category
>>> names
>>> in your database
>>>
>>> In all cases, I'd recommand to use only *one* table like that:
>>>
>>> category
>>> --------
>>> category_id
>>> category_parent_id
>>> category_name
>>> category_language
>>>
>>> For possibilities 1 and 2 category_name might be a token (for
>>> Zend_Translate).
>>> For possibility 3, you'd rather put the localized name itself in
>>> category_name.
>>>
>>> Then, make a model which uses Zend_Locale and just operates on those
>>> categories where the current locale matches category_language.
>>>
>>> Regards,
>>> Moritz
>>>
>>>
>>
>> But the locale data are not only translataion of the name!
>>
>> Eg. category in english could be invisible and for czech lang.
>> could be
>> visible.
>> We can have many of lang. different options, so Zend_Translate is
>> really
>> unusable.
>>
>> Well my problem is, that i will use one Model for related entities
>> (tables
>> or views)
>>
>> It means one model for (tables/views: categories_cs, categories_de,
>> categories_ne...) another model for Products (tables/views:
>> products_cs,
>> products_de, products_en)...
>>
>> My solution is:
>>
>> abstract class Db_Table_Multilingual_Abstract extends
>> Zend_Db_Table_Abstract
>> {
>> const BASENAME = 'basename';
>> const LOCALE = 'locale';
>>
>> protected $_basename;
>> protected $_locale;
>>
>> public function __construct($config = array())
>> {
>> parent::__construct($config);
>>
>> if (isset($config[self::BASENAME]))
>> {
>> $this->_basename = (string) $config[self::BASENAME];
>> }
>>
>> if (isset($config[self::LOCALE]))
>> {
>> $this->_locale = (string) $config[self::LOCALE];
>> }
>>
>> $this->_name = $this->_basename . '_' . $this->_locale;
>> }
>> }
>>
>> class Category extends Db_Table_Multilingual_Abstract
>> {
>> protected $_basename = 'categories';
>> }
>>
>> $category1 = new Category(array('locale' => 'cs'));
>> $category2 = new Category(array('locale' => 'en'));
>>
>> But sucks me, because i need to extend the Zend_Db_Table_Abstract
>> class
>
没有评论:
发表评论