- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
public enum EventType {
Error,
Notification,
Success
}
...
String sEventType = String.Empty;
switch (eType) {
case EventType.Error:
sEventType = "Error: ";
break;
case EventType.Notification:
sEventType = "Notification: ";
break;
case EventType.Success:
sEventType = "Success: ";
break;
}
Follow us!
https://msdn.microsoft.com/en-us/library/f45fce5x(v=vs.110).aspx
Теперь вопрос: как выпустить библиотеку (без исходников) и дать возможность сделать кастомную локализацию, которая не потеряется при переходе на следующую версию?
Так вот. В либе написано:
И ``localizationLibrary`` туда спровайдил клиент. А дальше он ресурсы сам менеджит.
То есть нужно сделать так, чтобы клиент библиотеки управлял локализацией.
Один из способов этого добиться, это вшить это знание в код клиента (вариант со switch), другой способ -- сделать ресурсы у клиента и передать их в библиотеку.
Ресурсы лучше чем, что это стандартный способ работы с локализацией (наверняка толсто поддерживаемый средствами разработки)
А чем лучше вариант со свичем?
Как минимум, простотой исполнения и возможностью частичной локализации с возвратом base.GetLocalizationString(arg); в случае, если что-то не найдено.
?
это же еще нужно было определить 100500 "коротких" переменных типа RadGridStringId.ConditionalFormattingPro pertyGridRowTextAlignmentDescription
мне кажется, ты нихуя не шаришь с ресурсах венды.
делаешь 2 файла Strings.ru.resx и Strings.en.resx. в обоих создаешь таблицы, которые можно через копи-паст работать с переводами.
можно даже перестраховаться и сделать Strings.resx, откуда он будет тянуть по дефолту, и если нет в каком-то из файлов ресурсов перевода для текущего языка.
и не писать 100500 строчек лапши, не обрабатывать для каждого перевода значение по умолчанию...
знаешь сколько мне действий нужно совершить, чтобы добавить новую локализацию, при условии, что переводить буду не я?
скопировать из common.resx все переводы через CTRL+C/CTRL+V в эксель, прислат переводчику на албанский. после этого добавляю новый файл аля common.al.resx, и вставлю туда значение из экселя через CTRL+C/CTRL+V. добавлю новое значение в выпадающий список языков, и на этом моя работа будет закончина. а ты до вечера будешь свитчи писать, и обрабатывать значение по умолчанию.
и это ты считаешь, что у тебя простота использования лучше? я могу писать Solution.Resources.Common.Mystring и получать значение, которое всегда будет равно текущей локали. или же достаточно написать один метод типа
Ну конечно, если не ты, если делать полноценную локализацию тем более, если нужно много языков, то через ресурсы самый удобный способ делать.
Но если надо три строчки локализовать на один язык, который меняться не будет, то хардкод проще.
если посмотреть на страницу с классическими контролами, какой бы тяжелой она не была - OnInit - 5-15 строк, OnLoad так же 5-15 строк, а вся остальная логика находилась в своих обработчиках событий типа GridView_PageIndexChanged, или SaveChangesButton_Click, то эти же мудаки решили, что они не будут работать с событиями, они будут на клиенте инициировать PostBack, а дальше у контролов будет проперти IsPostBack. результат? в OnInit лапша на 800 строк, где обрабатываются все варианты событий, из серии, типа "нажали кнопку сохранить, и при этом в выпадающем списке объектов было выбрано Продукт".. я каждый раз как с проблема сталкивался используя их контролы, я находил решение на КБ, с таким же свитчем как мне достался в наследство, и сразу уходил курить.
и кстати, что еще забавно - они не умеют работать с версиями. каждый раз, когда они выпускают новую версию компонентов, у них по факту появляется отдельная сборка с версией в названии. типа DevExpressWebControls12 а потом DevExpressWebControls13, etc. и конечно же ключи у них разные. у них даже специальная тулза есть, чтобы при обновлении компонентов можно было в проекте поменять референсы на новые сборки.
про пост-шарповые ресурсы не знаю.
но пре-шарповые ресурсы были полным отстоем: винда пыталась делать все сама и очень сильно лажалась (включая мемори лики!). не говоря уже про то что пользователь не имел возможности язык через конфигурацию приложения поменять.
самая большая лажа была когда какого шрифта локализованого не хватало. в худшем случае - это случалось уже в локализованом инсталлере. запускаешь инсталлер - а он тебе кракозябы или вопросики показывает.
Винда в доюникодовскую эру показывала вопросики, если не могла перекодировать текст в локальную кодировку. Т. е. если при кодировании (кодировка программы)→(unicode)→(кодировка пользователя) происходят потери.
Кракозябры же появлялись, если программист имеет ограниченный кругозор и не догадывается, что кроме его любимой кодировки в мире существуют и другие. Точнее, если он вообще забывает указать, в какой кодировке его текст, наивно полагая, что у пользователей будет та же кодировка и транслирование текста 1:1.
Итого: это проблемы восьмибитных кодировок (и семибитных, потому что тупые америкосы забывают про алфавиты, отличные от латинского).
проблема в том что этот программист сидел в некрософте, и из-за него очень много других страдали.
например локализованый мсоффис тех времен перебивал маппинг кодовых страниц популярных шрифтов. если локализация виндов не совпадала с локализацией оффиса, то маппинг ехал в ж, и куча приложений - за исключением самого оффиса - начинала показывать кракозябы.
> это проблемы восьмибитных кодировок
в виндах тех времен других просто не было.
почему народ ресурсы сам всегда в те времена и делал.
ЗЫ на самом деле "8-бит шрифт" это технически не правда. таблица маппинга символов внутри шрифтов уже давно могут юникод. проблема что ОС не поддерживала юникодные кодировки. поэтому юникод шрифт на Win9x был бесполезен (я пытался с winnt на win98 шрифты ручками перетаскивать).
Не совсем так. У MS было три типа шрифтов:
1. Совсем не юникод. Использовались в Windows 3.x.
2. Почти юникод. Использовались в Windows 95, 98, Me.
3. Совсем юникод. Использовались в Windows NT.
В общем, в Windows 95/98 всё было хитро: в некоторых местах юникод поддерживался, в некоторых — нет. В 95/98 были шрифты промежуточного формата, с табличкой, отличающейся как от 3.x, так и от NT.
нет. не было там ничего хитрого: юникод не поддерживался.
единственная реализованая wide функция - MessageBoxW().
даже функции конверсии кодировок текста юникод не поддерживали. (начиная с Win98SE одна из функций начала поддерживать конверсию юникода.)
я в свое время все выньапи в лоб прочесал в поиске возможности с юникодом на win9x работать.
> В 95/98 были шрифты промежуточного формата, с табличкой, отличающейся как от 3.x, так и от NT.
грубо говоря да. я предпочитал говорить раньше что версии TTF отличались. но TTF в жопу не версионирован - он просто контейнер с именоваными блоками. присутствующие в файле блоки определяют "версию".
В Windows 3.x была отдельная версия каждого шрифта под каждую кодировку (Arial CE, Arial Cyr etc.), а в Windows 95 от этих CE и Cyr избавились, собрав символы изо всех кодировок в один шрифт. Т. е. в одном шрифте уже был представлен фрагмент юникода, но какими функциями можно было вытащить все эти символы, я не уточнял.
*****
В Windows 95 (даже в первом выпуске, а не OSR) ресурсы в экзешниках были в Юникоде. Каким образом они использовались?
Кстати, это свидетельствует о том, что в Windows 95 какая-то внутренняя функция для перекодировки в Юникод и обратно была.
ты точно путаешь это с WinNT & NTFS.
FAT всегда был в локальной кодировке - что короткие, что длиные имена.
по этой причине тогда народ (с выходом w2k) повально валил на NTFS.
Попробуй отформатировать флешку в FAT и снять дамп, чтобы убедиться.
Windows 95 писала имена файлов на диск в том же формате, хотя через API доступа к юникоду не было. Вероятно, трансляция юникод<->локальная кодировка происходила внутри драйвера VFAT.
у меня дома есть Win98 в виртуалке. приду с работы проверю.
не были они там на рузу в Юникод.
ты однозначно путаешь это с WinNT.
75% штатных эксешников на Win9x были все еще DOS/Win16, а не Win32.
calc.exe из Windows 95. Имеет формат PE (Win32), а не NE (Win16). В ресурсе у латинских букв каждый чётный байт равен нулю.
Кто-то и в 2016-м году использует Windows XP...
P.S. А в середине 90-х у нас даже Windows 3.x были редкостью, ибо повсеместно использовался DOS.
Я поставил ей dosbox, и все ожило. На дворе стоял 2011й год.
Знакомая родилась уже _после_ того как вышел 386й с его 32битным режимом
2.ооп
3. Локализация на switch'ах