Translatable fields are not always created during table scan

[Alexander Obuhovich]

Each field in unit config can have formatter class set. When formatter is set to "kMultiLanguage" class, then during table scanning (when adding new language or pressing "Rebuild Multilingual Fields" in "System Tools" section) missing translatable fields are created, so we have 1 field for each language, like "l<LANGUAGE_ID>_<FIELD_NAME>".

• When "<FIELD_NAME>" is found in table, then it's parameters are used to create new translatable fields.
• When "<FIELD_NAME>" is not found, then we create translatable fields based on information from field declaration in unit config.

There is an error in regular expression, that checks, that we already have given field created in table resulting field being reported as existing, but it doesn't in fact. For example when you have field "DestName" in table and you have translatable field "Name", then "DestName" is matched instead of "Name" and none translatable fields are added.

Task: http://tracker.in-portal.org/view.php?id=692
Patch attached. Required to perform upgrade to 5.1.0 and therefore will be scheduled to 5.0.3.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Dmitry A.]

Never across this problem, but I guess it wasn't just easy reachable.

Thanks for the patch - will test and report back.

DA.

On Apr 10, 7:25 am, Alexander Obuhovich <aik.b...@gmail.com> wrote:
> Each field in unit config can have formatter class set. When formatter is
> set to "kMultiLanguage" class, then during table scanning (when adding new
> language or pressing "Rebuild Multilingual Fields" in "System Tools"
> section) missing translatable fields are created, so we have 1 field for
> each language, like "l<LANGUAGE_ID>_<FIELD_NAME>".
>

>    - When "<FIELD_NAME>" is found in table, then it's parameters are used to
>    create new translatable fields.
>    - When "<FIELD_NAME>" is not found, then we create translatable fields