Hi guys,
the idea to copy all values from one language to another could be the
right one, but it could also mask a global problem dealing with lang
pack. I had another issue of the same type as follow:
I installed a fresh 501, and uploaded the french lang pack. After
setup French as primary lang for admin and front-end, I started to
create my first category.
I had an error message when I tried to save it, and I noticed in the
top right corner of the category window that I was sticked on
"english", and even after changing the value in drop down, it was
coming back to English. I closed the category editing window, and
changed the top right lang selector to choose french langage.
After this change, the category creation were going fine, but I
discovered that the catalog tree wasn't showing sections anymore.
Dmitry had a quick look and found that it's because english value were
still used to display tree names, while admin interface is in French
(as related in
http://tracker.in-portal.org/view.php?id=349 )
Cheers
Phil.
On Nov 9, 7:27 pm, Dmitry <
dandre...@gmail.com> wrote:
> Yes, I think this is the case - we definitely need to copy all values in
> all ML fields from OLD Primary to NEW Primary for missing ones.
>
> How do we find missing ones - IS NOT NULL?
>
> Do we have a bug in Issue Tracker for this yet?
> --
>
> --
> Best Regards,
>
> Dmitry V. Andrejev
>
> -----Original Message-----
> From: Alexander Obuhovich <
aik.b...@gmail.com>
>
> Reply-To:
in-port...@googlegroups.com
> To:
in-port...@googlegroups.com
> Subject: Re: Multilingual field sorting sometimes doesn't work
> Date: Mon, 9 Nov 2009 20:21:27 +0200
>
> I've made a patch already, but forgot to attach it in my first post.
> I've attached it now. Two order by fields will only raise problems in
> case if fields in both languages are filled. Related to new record this
> is only the case, when you have products in database and you add new
> language and make it primary. In this case all products become invalid.
>
> When primary language is changed, then we could copy values (for all
> tables) from old primary language fields to new primary language fields
> in case if they are missing in new primary language fields. This way
> required multilingual fields will be filled and all items will be valid.
>