1. Избавляемся от ключей. Вместо ключа (типа MainPageHeaderText1) юзать сам текст (ака "My Cool Service"). Ключи -- лишняя сущность. Они допустимы только когда текста реально много.
2. Одного текста не достаточно -- нужна еще и категория, иначе сложно переводить (не ясно к чему относится). Т.е. в итоге присвоение строке локализованного значения выглядит примерно так:
headerText = Translate(nameof(Page1), "My Cool Service");
При желании вместо "My Cool Service" можно указать и ключ, если текст очень длинный.
3. Список на локализацию должен формироваться автоматически. Т.е. открыли страницу а перевода для фразы "My Cool Service" еще нет. По умолчанию отдается то что в коде и сразу же создается запись в таблице переводов (с пустым переводом, конечно). Т.е. чтобы собрать полный список на перевод -- вам всего лишь нужно пройтись по всем возможным формам приложения (а без этого и не протестите).
Т.е. вручную не нужно вносить "My Cool Service" в базу -- оно там само появится, как только выполнится Translate(nameof(Page1), "My Cool Service"). А далее можете отдавать переводчику все что есть в базе. Если там появилось не все -- значит тестеры открыли не все страницы и/или протестировали не все возможные ситуации.
Здравствуйте, Shmj, Вы писали:
S>1. Избавляемся от ключей. Вместо ключа (типа MainPageHeaderText1) юзать сам текст (ака "My Cool Service"). Ключи -- лишняя сущность. Они допустимы только когда текста реально много.
В результате когда текст надо слегка поменять — надо бежать по всем локализованным версиям.
S>2. Одного текста не достаточно -- нужна еще и категория, иначе сложно переводить (не ясно к чему относится).
А чего не обойтись композитным ключем типа Page1.HeaderText?
S>3. Список на локализацию должен формироваться автоматически. Т.е. открыли страницу а перевода для фразы "My Cool Service" еще нет. По умолчанию отдается то что в коде и сразу же создается запись в таблице переводов (с пустым переводом, конечно).
Чем создается? Для нормальных resx хотя бы поддержка решарпера есть.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>В результате когда текст надо слегка поменять — надо бежать по всем локализованным версиям.
Зачем? Для языка по умолчанию (английского) тоже создается запись в базе, но пустая. Если хотите поменять только английскую версию -- то можно это пустое значение заполнить, тогда будет отдавать не то что написано в коде а из базы.
S>>2. Одного текста не достаточно -- нужна еще и категория, иначе сложно переводить (не ясно к чему относится). AVK>А чего не обойтись композитным ключем типа Page1.HeaderText?
Ключи вообще не удобны, ни о чем. Лучше иметь полный текст и категорию.
S>>3. Список на локализацию должен формироваться автоматически. Т.е. открыли страницу а перевода для фразы "My Cool Service" еще нет. По умолчанию отдается то что в коде и сразу же создается запись в таблице переводов (с пустым переводом, конечно).
AVK>Чем создается? Для нормальных resx хотя бы поддержка решарпера есть.
А в чем заключается эта поддержка?
Создается так. Видите строку, которую нужно локализовать. Берете и вставляете туда Translator.Instance.Translate(). Никаких тебе ключей и прочего геммора.
Сначала хотел согласиться, но и с поинтами Андрея спорить на самом деле глупо...
Я в своей практике всегда посылал все resx на все четыре стороны потому что:
а) строки локализации у меня чаще всего лежали в базе;
б) resx — это изобретение ради изобретения, оно само по себе вообще не нужно, и существует только если не мешает, во всех остальных случаях — ЭТО нужно давить нахрен; (понятно, что winforms и подобное не может жить без этого, но... прикрутить string table можно раз в 10-100х эффективнее чем это сделали господа из МС, но, опять же — локализация — не только строки может и иконки).
в) локализация/глобализация проектов — дело *интимное*. вот все эти хэлло-ворды из примеров — они не нужны. они не отражают реальных требований вообще. оно умирает на реальных проектах. оно работает так же пахабно как оно работает в студии. особенно в купе с дебильным переводом (но это уже не про программирование).
Посему, я вот лично — просто резко против resx как "технологии", если его так можно назвать. Любое своё решение в моей практике — на 2 порядков проще и лучше. Я вообще считаю что всё API по дефолту должно работать с нейтральной культурой (ну и потоки не должны её наследовать). Но это сугубо мои личные предпочтения. А живём мы в другом мире, поэтому... простите, крик души и забыли.
По факту — я думал и даже начал реализацию где-то рядом того, что ты говоришь, но потом быстро забросил, т.к. в проекте это просто не было нужно. Имхо, в коде — не важно как построена подсистема — легче всё таки использовать идентификаторы, иначе — при синтаксических правках — боль обеспечена. Боль обеспечивается не самой правкой, а политикой мерджа в моём случае. Скажем, ты работаешь в проекте, где мерджи в девелоп!!! ветку происходят спустя 2 месяца реального времени после, того как реальные изменения сделаны — всё — это смерть. А банальные синтаксические правки — происходят. Использование просто идентификаторов позволит тебе вообще не касаться этого вопроса, строку поменяют и без тебя. А вот с тем подходом, что ты предлагаешь — это всё будет пропущено через тебя или других разработчиков сто процентов. Хотя, я хочу подчеркнуть, что универсального то решения и нет — в разных проектах работают разные решения.
Если думаешь, что твоя идея будет работать у тебя в проекте — так вперёд. Воплоти, внедри. Потом поделишься опытом тут... наоборот, все спасибо скажут. А так... в общем случае — конечно, это будет неудобно (хотя плюсы тоже есть). Просто, любой программист сможет пронавигироваться по ИД и получить строку. Наоборот — нет. Более того — по идентификаторам легче искать в коде где именно генерируются ошибки конкретного типа (ну т.е. приводящие к одному и тому же описанию хотя бы. если этого недостаточно — то можно ввести их классификацию, навроде как это делают в компиляторах). Опять же — я часто делаю поиск по файлам прям из студии — бывают ситуации — где она не может навигироваться. Или знаю ключевое слово. Ну вот, такое решение, имхо просто добавит ещё в этот список кейсов и всё.
А на сухом выходе: не стандартная система, неясно как её мэйнтэйнить (кому-то кроме тебя или тем кого ты посвятишь), ну и тому подобные. Можно так до бесконечности.
Вот. Короче. Не вижу смысла париться. Попытайся объяснить тут преимущества своего подхода, и вероятнее всего, ты и сам поймешь, что те убогие средства, что есть — достаточны. Ну а комфорт — это уже от себя — никто ж не запрещает. Что впрочем не значит, что в твоём случае не нужен твой подход... Формуа щастя то где затраты меньше, а профита больше. Тут имхо так никогда не будет. Просто потому что *любые* уникальные решения дорогие по определению: никто с ними не знаком. Новые коллеги не знают их и т.п. Короче в плане мэйнтэйнмента — это не просто сделать правильно.
К чему стремишься ты — мне лично не очень ясно, но так или иначе — решение по прежнему за тобой.
PS: Средства на подобии того что ты начал описывать существуют ещё с прошлого тысячелетия. Реального распространения они не получили. Банально потому, что, ты как программист нередко хочешь сгенерировать E0001 и E0002 с одинаковым текстом ошибки, особенно если он (текст ошибки) вообще приезжает из третьего места. А код ошибки тут показывает место (кол-стэк НЕ МОЖЕТ его показать). Ну...
PPS: Если готов отдать своё время — так попробуй сделать чего хочется. Вместе с этим, имхо, следует сфокусироваться на решении проблемы более-менее стандартными способами: таким образом даже последователи более-менее должны быть в курсе. Имхо, как-то так. Короче, будующий мэйнтйэнмент важнее сиюминут.
Здравствуйте, Shmj, Вы писали:
S>Вот к чему пришел:
S>1. Избавляемся от ключей. Вместо ключа (типа MainPageHeaderText1) юзать сам текст (ака "My Cool Service"). Ключи -- лишняя сущность. Они допустимы только когда текста реально много.
S>2. Одного текста не достаточно -- нужна еще и категория, иначе сложно переводить (не ясно к чему относится). Т.е. в итоге присвоение строке локализованного значения выглядит примерно так:
S>Критика?
Это ты gnu gettext что ли описываешь? Ему скоро 30 лет исполнится. Можно конечно, но поддержка тулов в студии для C# AFAIK околонулевая.
А вообще там система давно и тщательно продумана, см. например ".PO" файлы — переводческий стандарт в некотором роде.
Есть и реализация для .net
Но нафига оно в студии, есть например решарпер и ResX Manager?
Нажал на строчку, Alt+Enter "Move to resources". Повторил для всех нужных.
Открыл ResX Manager, экспортнул/импортрул/перевел. ы?
Здравствуйте, bnk, Вы писали:
bnk>Но нафига оно в студии, есть например решарпер и ResX Manager? bnk>Нажал на строчку, Alt+Enter "Move to resources". Повторил для всех нужных.
Во-первых, для решарпера нужно сначала создать этот файл с ресурсами. Ведь нам нужно разбивать на категории, значит ресурсный файл будет не один. Без разбивки на категории сложнее переводить. Создание таких файлов -- лишний геммор. Да и выбирать из длинного списка не удобно.
А главное. Что если вам нужно перевести строку из некого источника данных? К примеру из JSON-файла. У меня все просто -- передал имя в функцию и получил готовый перевод. А вы как сделаете?
Здравствуйте, Shmj, Вы писали:
AVK>>В результате когда текст надо слегка поменять — надо бежать по всем локализованным версиям. S>Зачем?
Затем что это ключ.
S> Для языка по умолчанию (английского) тоже создается запись в базе, но пустая. Если хотите поменять только английскую версию -- то можно это пустое значение заполнить, тогда будет отдавать не то что написано в коде а из базы.
А для других языков что делать? Они то отвалились при изменении ключа.
S>>>2. Одного текста не достаточно -- нужна еще и категория, иначе сложно переводить (не ясно к чему относится). AVK>>А чего не обойтись композитным ключем типа Page1.HeaderText? S>Ключи вообще не удобны, ни о чем.
Это аргумент твой ни о чем.
S> Лучше иметь полный текст и категорию.
Не лучше. Хотя бы потому что полный текст не всегда полностью отражает суть.
AVK>>Чем создается? Для нормальных resx хотя бы поддержка решарпера есть. S>А в чем заключается эта поддержка?
Да много в чем. Ненужные показывает, к примеру.
S>Создается так. Видите строку, которую нужно локализовать. Берете и вставляете туда Translator.Instance.Translate().
Руками? И в чем прогресс?
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Shmj, Вы писали:
bnk>>Но нафига оно в студии, есть например решарпер и ResX Manager? bnk>>Нажал на строчку, Alt+Enter "Move to resources". Повторил для всех нужных.
S>Во-первых, для решарпера нужно сначала создать этот файл с ресурсами. Ведь нам нужно разбивать на категории, значит ресурсный файл будет не один. Без разбивки на категории сложнее переводить. Создание таких файлов -- лишний геммор. Да и выбирать из длинного списка не удобно.
Оно само по умолчанию создаст, если один. Если несколько — то да, нужно отдельно (можно через ResX Manager).
Я в этом смысла особого не вижу, честно говоря. Можно просто идентификаторы делать с категорией, если нужно для контекста.
Типа CategoryX_WarningMessageFileNotFound. Идентификатор придумывать не надо, его решарпер сам придумать может — там есть правила встроенные.
S>А главное. Что если вам нужно перевести строку из некого источника данных? К примеру из JSON-файла. У меня все просто -- передал имя в функцию и получил готовый перевод.
В этом случае да, облом. Этот подход работает для локализации самих приложений, а не данных в этих приложениях.
То есть подразумевается, что локализуемые строчки известны на этапе компиляции. Если они приходят откуда-то извне во время работы,
То откуда ты узнаешь что это будут за строчки? В JSON же может прийти что угодно, не?
S> А вы как сделаете?
В своих продуктах делаю тупо resx по схеме выше (но они относительно небольшие).
В проектах которые делал в контрах использовался специализированный софт (у нас был сначала lingobit потом rc-wintrans, и но они оба отстойные — с контролем версий например был швах).
Зато позволяют объединить в одном проекте все файлы переводов — resx, xml, po, wxl, данные в базе и т.п.).
Если проект составной и разношерстный, помогает навести порядок.
Здравствуйте, Shmj, Вы писали:
S>1. Избавляемся от ключей. Вместо ключа (типа MainPageHeaderText1) юзать сам текст (ака "My Cool Service"). Ключи -- лишняя сущность. Они допустимы только когда текста реально много.
Сразу появляется проблема "протухания" переводов. Подправил программист текст сообщения и все переводы привязанные к нему протухли.
Такая система будет работать только при условии контроля компилятора. Чтобы при изменении основного сообщения компилятор не дал собраться, пока не будут обновлены все переводы.
Но это вызовет другую проблему — переводы придется править самому программисту. А если не все переводы доступны во время сборки (что нормально при внешнем переводе), то будут большие проблемы.
Ну, и такую систему без макросов создать не просто. Это надо ее в язык программирования вмонтировать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>В результате когда текст надо слегка поменять — надо бежать по всем локализованным версиям. S>>Зачем?
AVK>Затем что это ключ. AVK>А для других языков что делать? Они то отвалились при изменении ключа.
Объясняю.
Допустим, в коде вы написали: "My Pеge" (ошибка)
При запросе из eu-Culture автоматически создается запись для языка en с значением My Pеge = null. Если null -- значит возвращаем значение из кода. Аналогично для всех языков. Т.е. нет языка по умолчанию, он условен.
Если нужно изменить только для английского -- заменяете в базе null в английской версии на My Page. При этом остальные языки можно не трогать.
S>> Лучше иметь полный текст и категорию.
AVK>Не лучше. Хотя бы потому что полный текст не всегда полностью отражает суть.
Никто не мешает добавить примечание
S>>Создается так. Видите строку, которую нужно локализовать. Берете и вставляете туда Translator.Instance.Translate(). AVK>Руками? И в чем прогресс?
А в том что не нужно в ресурсах ничего писать -- все появляется само при первом запросе.
А еще. Что если вам нужно перевести строку из некого источника данных? Т.е. вы получаете переменнуд tagName и у нее может быть с 15 разных значений.
Мне достаточно передать в Translate и забыть. А вы что будете делать?
Здравствуйте, VladD2, Вы писали:
VD>Сразу появляется проблема "протухания" переводов. Подправил программист текст сообщения и все переводы привязанные к нему протухли.
Ну а как? Ведь после испрвления нужно менять переводы, иначе никак.
Если появится новая строка с null -- это сразу будет видно.
VD>Такая система будет работать только при условии контроля компилятора. Чтобы при изменении основного сообщения компилятор не дал собраться, пока не будут обновлены все переводы.
Нет, компилятор должен проверять код а не переводы. Если приложение локализовано не полностью -- в 90% случаев это не критично.
А для переводчика есть утилита, которая отображает строки со значением null и он сразу видет что нужно перевести.
VD>Но это вызовет другую проблему — переводы придется править самому программисту. А если не все переводы доступны во время сборки (что нормально при внешнем переводе), то будут большие проблемы.
Зачем самому? Небольшая утилита покажет какие строки со значением null.
Здравствуйте, Shmj, Вы писали:
S>Ну а как? Ведь после испрвления нужно менять переводы, иначе никак.
Если ключ "суррогатный", то он не протухает. При изменении оригинального текст можно легко это отследить и дать сигнал переводчикам, что нужно обновить переводы.
Если же ключ — это сам текст, то будет просто "повисший" перевод (перевод принадлежащий неиспользуемому в программе ключу).
S>Если появится новая строка с null -- это сразу будет видно.
Почему с null? Появится новый ключ вообще без перевода и "подсевшие" ключи с переводом. Через некоторое время отследить все изменения будет невозможно.
S>Нет, компилятор должен проверять код а не переводы.
Если у тебя текст — это ключ, то это и есть код. Ты же его как идентификатор используешь.
S>А для переводчика есть утилита, которая отображает строки со значением null и он сразу видет что нужно перевести.
И им всегда делать переводы с нуля? То есть программист правит одну опечатку, а переводчик должен переводить весь текст?
S>Зачем самому? Небольшая утилита покажет какие строки со значением null.
Ну, если тебя устраивает работа переводчика на любой чих программиста, то можно и так.
Только утилиту эту твою тоже создать не так то просто. Информацию о том, что какая-то строка — это ресурс нужно ведь как-то вынуть. При наличии макросов — это не проблема. А так тебе придется делать некий "выпарсиватель" таких строк. Вводить какие-то соглашения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, VladCore, Вы писали:
VC>>Вы опоздали. bnk уже написал что в gettext именно так. И как ни странно в .NET Core тоже.
S>В gettext не так удобно -- там нет категории.
Зато есть файлы, имя файла чем не имя категории?
Ну и gettext-у в два раза больше лет чем resx и ResourceManager. Почему он не здох до сих пор как думаеш?
S>А в .Net Core значения все сами добавляются? Куда и в каком формате?
Здравствуйте, VladD2, Вы писали:
VD>Если ключ "суррогатный", то он не протухает. При изменении оригинального текст можно легко это отследить и дать сигнал переводчикам, что нужно обновить переводы.
А как отследить? Записывать в блокноте?
В моей системе все отслеживается автоматически -- как только оригинальный текст был изменен -- сразу же появится новый ключ с null-значением. Все просто.
VD>Если же ключ — это сам текст, то будет просто "повисший" перевод (перевод принадлежащий неиспользуемому в программе ключу).
Делаете так. Берете и заново проходитесь по проге, прогоняя все тесты. При этом старые файлы/таблицы с переводами удаляете.
После этого будут только актуальные значения. Мерджите (5 строчек кода) и в новой версии у вас уже не будет не актуальных ключей.
S>>Если появится новая строка с null -- это сразу будет видно.
VD>Почему с null? Появится новый ключ вообще без перевода и "подсевшие" ключи с переводом. Через некоторое время отследить все изменения будет невозможно.
Вообще без перевода -- это и есть с null. Значит его нужно перевести. Как удалить старые -- см. выше.
S>>Нет, компилятор должен проверять код а не переводы. VD>Если у тебя текст — это ключ, то это и есть код. Ты же его как идентификатор используешь.
Это ошибочная парадигма. Отсутствие перевода -- это не критично, скорее варнинг. Не причина для ошибки компиляции.
S>>А для переводчика есть утилита, которая отображает строки со значением null и он сразу видет что нужно перевести. VD>И им всегда делать переводы с нуля? То есть программист правит одну опечатку, а переводчик должен переводить весь текст?
Почему весь текст? Только те записи которые null (новые добавляются в таблицу/файл автоматом и значение устанавливается в null).
S>>Зачем самому? Небольшая утилита покажет какие строки со значением null. VD>Ну, если тебя устраивает работа переводчика на любой чих программиста, то можно и так.
Если изменился текст -- это не любой чих. Значит и переводы нужно изменить.
VD>Только утилиту эту твою тоже создать не так то просто. Информацию о том, что какая-то строка — это ресурс нужно ведь как-то вынуть. При наличии макросов — это не проблема. А так тебе придется делать некий "выпарсиватель" таких строк. Вводить какие-то соглашения.
В теории можно было бы добавить поддержку на уровне языка. К примеру все строки #"test string" -- автоматом локализуются.
Здравствуйте, VladCore, Вы писали:
VC>Зато есть файлы, имя файла чем не имя категории?
Слишком привязано к исходникам. А переводчику важен не исходник а форма. Он же будет смотреть в сайте или проге в какой форме написан тот или иной текст, если возникнут вопросы.
VC>Ну и gettext-у в два раза больше лет чем resx и ResourceManager. Почему он не здох до сих пор как думаеш?
Потому что концепция правильная, мудрая.
S>>А в .Net Core значения все сами добавляются? Куда и в каком формате? VC>Хз. Гайдов полно.
А что рекомендуют? Я еще не смотрел, от вас узнал.
Здравствуйте, Shmj, Вы писали:
S>Вот к чему пришел:
S>1. Избавляемся от ключей. Вместо ключа (типа MainPageHeaderText1) юзать сам текст (ака "My Cool Service"). Ключи -- лишняя сущность. Они допустимы только когда текста реально много. S>2. Одного текста не достаточно -- нужна еще и категория, иначе сложно переводить (не ясно к чему относится). Т.е. в итоге присвоение строке локализованного значения выглядит примерно так: S>
S>headerText = Translate(nameof(Page1), "My Cool Service");
S>
А что мешает использовать ключи A_My_Cool_Service_Header
S>При желании вместо "My Cool Service" можно указать и ключ, если текст очень длинный.
S>3. Список на локализацию должен формироваться автоматически. Т.е. открыли страницу а перевода для фразы "My Cool Service" еще нет. По умолчанию отдается то что в коде и сразу же создается запись в таблице переводов (с пустым переводом, конечно). Т.е. чтобы собрать полный список на перевод -- вам всего лишь нужно пройтись по всем возможным формам приложения (а без этого и не протестите).
А если от перевода зависит не текст а число? Например ширина полей, количество строк, или картинка, или шаблон внешнего документа.
S>Т.е. вручную не нужно вносить "My Cool Service" в базу -- оно там само появится, как только выполнится Translate(nameof(Page1), "My Cool Service"). А далее можете отдавать переводчику все что есть в базе. Если там появилось не все -- значит тестеры открыли не все страницы и/или протестировали не все возможные ситуации.
Это значит вы должны как-то выкатить список всех страниц (N штук) и список свеже изменённых, а так же метод быстрого их открытия по номеру от 1 до N.
Если на 100500 странице найдена опечатка, то как-то идентифицировать где её искать чтобы исправить?
А если количество возможных ситуаций растёт непотребно быстро?
Здравствуйте, kov_serg, Вы писали:
_>А что мешает использовать ключи A_My_Cool_Service_Header
Это лишняя сущность -- они не нужны.
Их не удобно читать, гораздо приятнее читать нормальный текст чем коверканный.
Еще придумывать название, не всегда из названия понятны к чему относится. Лишняя трата времени.
_>А если от перевода зависит не текст а число? Например ширина полей, количество строк, или картинка, или шаблон внешнего документа.
Ширина полей и количество строк -- это не те вещи, которые разумно локализовать. Документ должен сам подбирать свои размеры на основе данных.
Картинку -- локализуйте имя файла, а как еще?
Шаблон -- локализуйте имя шаблона.
S>>Т.е. вручную не нужно вносить "My Cool Service" в базу -- оно там само появится, как только выполнится Translate(nameof(Page1), "My Cool Service"). А далее можете отдавать переводчику все что есть в базе. Если там появилось не все -- значит тестеры открыли не все страницы и/или протестировали не все возможные ситуации. _>Это значит вы должны как-то выкатить список всех страниц (N штук) и список свеже изменённых, а так же метод быстрого их открытия по номеру от 1 до N.
Все равно тесты должны быть. Вдруг ваша страница вообще не работает -- как узнать не проверив? А вот сразу после запуска теста все новые данные и добавятся в таблицу.
_>Если на 100500 странице найдена опечатка, то как-то идентифицировать где её искать чтобы исправить?
Для этого и существует категория. Категория позволяет работать с небольшой порцией данных для локализации и всегда знать где искать.
может и иконки).
