Axapta и Ин. языки

[SIRS]

Есть необходимость отображать в Axapta (3.0 SP4) метки на турецком языке...

Просто подмены меток и настройки конфигурации на клиенте (что и не удивительно) оказалось недостаточно - на тестовой машине (Windows XP) установили региональные настройки як в Турции, в реестре (HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/ CurrentVersion/FontSubstitutes) прописали для всех фонтов кодировку 162 вместо 204 - получили Axapta на турецком языке. Но... Понятное дело, что после такого издевательства над системой все данные пошли кракозябрами... В Axapta, как известно, можно задать фонт для, например, форм, что и было проделано. Для некого шрифта предварительно вернули 162 кодировку, в Axapta установили для форм этот шрифт и.... Получили данные на русском и черт знает что на контролах формы, метки которых имели тот же шрифт, что и данные. Отловленный для экспертизы турок подтвердил, что метки вроде бы турецкие, но не полностью - часть турецких 'спец' символов отображались символами, скорее имеющими отношению к нашему алфавиту... )

Мы зарегистрировали проблему в Microsoft. Однако, пока кроме документа на тему поддержки Unicode в Axapta (японский, китайский язык и т.д) и красочных обещаний, что в Axapta 4.0 всё будет хорошо, мы не получили.

После вышеуказанных попыток решили основательно проверить 2 гипотезы:
1) Попробовать менять фонты на отдельных контролах формы
2) Воспользоваться параметром конфигурационной утилиты Initialize database for Unicode

Айтишники предоставили нам комп с установленной английской XP (предлагали на выбор и русскую, но откуда на машине, хозяин которой турок, может стоять русская XP? ). Установка турецких региональных настроек сразу нам дало возможность увидеть Axapta на чистом турецком языке (в предыдущий раз тоже с XP, но русской, пришлось хорошо разгуляться в реестре, правя кодировки шрифтов, а на Windows 2000 любые экзортизмы оказались безуспешными). Итак, турецкую Axapta мы получили, русские данные потеряли - кракозябра на кракозябре сидит и кракозяброй погоняет. Стали менять шрифты на дизайне формы и контролах - благо при установке отличного шрифта можно выбрать и набор символов. Результаты были так себе - данные в гридах вроде бы русские, однако, при простановке курсора в поле грида опять видим кракозябры. С этим можно было бы смириться. Но..... Отдельностоящие контролы упорно отказываются показывать такие милые моему сердцу русские буквы, что с ними не делай. Что странно. Очень.

Далее, мы попытались воспользоваться параметром Initialize database for Unicode в конфигурационной утилите. В этом случае при синхронизации приложения на чистой БД стринговые поля таблиц определяются типом nvarchar, а не varchar как обычно. экспортом\импортом из Axapta несколько справочников в новую БД. Никакого отличия в лучшую сторону от описанного выше не увидели.

Если кто-то может подкинуть чуток предложений (предположений, гипотез, подозрений) по поводу, будем признательны...

Окружение:
Axapta 3.0 SP4
СУБД: SQL Server Developer Edition SP4 Collation: Cyrillic_General_CI_AS
Windows XP SP2 английская

[MironovI]

Использование китайского на формах при турецкой кодировке у вас русских данных и не будет.. в трешке..

Да но они могут поставить русскую кодировку а в формах по описанной процедуре в ссылке (смена на греческий заголовка окна) менять символы на турецкие. Ессно это подозрение, но может выгореть . Хотя турков жалко но все же вариант

[EVGL]

Дело ваше гиблое."Initialize database for Unicode" позволят одновременно забивать в одну у ту же базу русские данные с русского компьютера, а турецкие - с турецкого. Данные лежат правильно, но при попытке отобразить на русском компьютере турецкие данные они (данные) отрисовываются "крякозябрами". И не пробуйте сохранять запись, тогда "крякозябры" запишутся обратно в базу!

Резюме: для каждого языка данных - своя компания и свой компьютер. Хотите заглянуть в чужую компанию - возьмите турецкий компьютер и переключитесь на английский интерфейс.

[MikeR]

А что государственный English в Турции отменен?