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
Václav Vaník schrieb:
> Moritz Mertinkat napsal(a):
>> If your categories are the same for each language, I'd rather use
>> Zend_Translate than maintaining different sets in your database.
>>
>> If there's a reason to keep it in database or if your categories
>> differ from
>> language to language, I'd still use the same table, as it makes things
>> a lot
>> easier in general. You also wouldn't need to different Zend_Db_Tables
>> and thus
>> no redundant code.
>>
>> Use Zend_Locale and a model which selects the right categories from your
>> database using "Categories extends Zend_Db_Table" depending on the
>> locale/language.
>>
>> Maurice.
>
> Well my idea is we have two possibilities:
>
> a) language "different categories", so i wont use views (categories_cs
> and categories_en) but i use tables categories_cs and *_en
>
> b) same categories for each language, it means i will use views
> because in language A could be the category visible and in language B
> could be invisible and so...
没有评论:
发表评论