BiTel

1. К чему абоненту типы платежей и расходов? 0_о Эта классификация используется только для нужд самого оператора.

2. Названия тарифных планов, теоретически да. Но на практике в подавляющем большинстве государств по закону названия товаров и цены должны указаны на государственном языке. Или, как правило на одном из...
Это только в Канаде по-моему обязательно на двух языках... Но я сомневаюсь, что Канада это актуальный рынок для BGBilling'а.

3. С новостями я не вижу проблем. Вариантов куча. Например, можно делать отдельные списки рассылки для разных языков и постить соответствующие новости в соответствующие списки...

4. Справочники в массе своей по тому же принципу, что и в пункте 2. Например, я нигде ни разу не видел, чтобы где-то улицы официально именовались на двух языках. Максимум для туристов могут латиницей названия написать. Но это вовсе не официальные названия и оперировать такими названиями в биллинге вряд ли стоит.

Мультиязычность как правило нужна лишь для удобства клиентов. Для этого достаточно, чтобы справочная информация (типа расшифровок и прочая), ну и сам личный кабинет были на удобном ему языке. Все официальные документы (сч.-ф., акты и т.п.) должны быть только на государственном языке и это должен быть основной язык в биллинге оператора.

Если вы переведете биллинг на utf, то большая часть проблем сама по себе отвалится. А кабинет в большинстве своем можно локализовать действительно средствами XSL... Ну, нахудой конец добавить поле а ля "название на альтернативном языке". 99,9% потребностей это закроет однозначно.

_________________
С уважением...

Названия платежей/расходов нужны чтобы на статистике, в разделе балланса показывать. Там же нужны названия улуг абон. платы.

Т.к. меня, с языками, походу недопоняли то расшифрую - юзер выбирает на статистике свой язык, у него где нибудь в профиле записывается цифра представляющая собой ID языка и после этого на его основании мы инклюдим нужную XSL-ку с переводом. Чтобы упростить надо просто каждой значимой позиции дать некий номер и по этому номеру и выдавать тот или иной вариант, например "платеж" имеет номер 10 тогда получается что:
10 = платеж - это в русской XSL-ке
10 = payment - это в англицкой XSL-ке
а в основной XSL-ке, которую используем для отрисовки просто пишем не "платеж", а 10 и вместо 10-ки подставится нужное слово, AFAIR так мультиязычность обычно и делается.

_________________
I'm clever. I've got a computer.

название платежей и расходов храниться в БД
подменять их в XSL будет сложновато

Вы меня простите, конечно. А-а, куда первый стал внедрять? И как, внедрили? То-то я смотрю в BGBilling's в качестве базового enconding используется ucs-2... Ой, постойте... BGBilling по дефолту использует cp1251, aka win-1251.

Вот это Microsoft действительно "внедрила", несмотря на то, что на тот момент уже существовала CP866, которая была на тот момент стандартом де-факто и более того утверждена как международный стандарт. Не буду поминать недобрым словом два десятка лет геморра после этого с русскими кодировками, перекодировками и прочая, которые до сих пор аукаются.

Судите по делам, а не по словам...

_________________
С уважением...

Надеюсь вы не меня имеете ввиду. Я вас отлично понял...

_________________
С уважением...

Внедрять стала в системные вызовы, API, описания, ресурсы и везде и всюду. Строго говоря, NT была как раз-таки полностью юникодная ещё тогда, когда не пахло юникодом не только в линуксах, но и линукс то сам только пахнуть начинал сам собой. А некоторые особо продвинутые системы (фрибсд и прочие) до 21 века дожили с кои8 и в ус не дуют. Всё, что вы говорите, про cp1251 — это наследие доса и беспонтовых досовых/виндовых быдлопрограммистов, и того, что микрософту 10(!) лет приходилось параллельно продвигать 9x и NT винды, причём с полностью совместимым API. В итоге КАЖДАЯ системная функция продублирована в API с разными суффиксами для ansi и widechar. Но внутри всё давно widechar. Всё это обратная совместимость и следствия правильного маркетинга. Хотя многое мне там тоже не нравится в этом плане. Уже 100500 лет в винде полагалось писать юникодные версии программ, но увы, всё не так просто. Эта cp1251 как дефолтная кодировка системы (не консоли, причём, где как раз была oem и до сих пор она там, по-моему) тоже из линейки 9x пришла. Если бы NT и 9X были разными ОС разных компаний, то и проблемы бы вообще не было. Да, и я думаю, что по-хорошему всё это надо было раньше прибить было, в момент где-то 95й винды и принудить проги писать в юникоде все, но почему-то всё по дефолту инструменты были настроены на однобайтовые кодировки.

_________________
I'm clever. I've got a computer.

Насколько я понял northbear не нужна мултиязычность . Он хочет хранить на одном языке , назовем его условно - эльфийский . Он хочет чтоб у него вся база была на эльфийском( соответственно названия тарифов , платежей , фамилии абонентов, новости и т.п ). xsl тоже на эльфийском. Для этого база должна быть в utf8 , xsl тоже в utf8. С русскими названиями в клиенте он , насколько я понял, готов смирится. Еще у нас в web некоторые сообщения об ошибках жестко вшиты в код на русском - это можно исправить.

Вам же сказали что для этого нужно сделать . Т.е. получается, что нам для поддержки utf8 нужно сделать то же самое.

Только конвертировать базы старых клиентов мы не будем, utf8 можно предложить тем, кто ставит с нуля . Мы можем, конечно, сделать по умолчанию utf8, но тогда у нас старые клиенты, будут скачивать клиент, сервер и сами руками менять кодировку . Поскольку их больше, несправедливо ставить их в неловкое положение. Т.е получается мы можем просто в документации написать как с нуля поставить под ut8 изначально и все . Т.е как таковая поддержка с нашей стороны кроме информационной не требуется. Да еще если кто-то работает одним клиентом с 2-мя биллингами , если один будет на cp1251, а второй на utf8, то нужно в клиенте кодировку выставлять в зависимости от сервера - это нужно доработать и отразить в документации.

столько сложностей для всех изза 1 человека, вы уж простите, но я не хочу у себя м*дохаться с кодировками

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

To: survivor
Если хотите решать вопрос _только_ с разработчиками - пишите в HelpDesk или на почту.
Форум открыт для всех, и высказаться в любой теме может каждый.
Вы могли более вежливо указать, что вас интересует именно принципиальное решение вопроса и вы ждёте предложений в этом ключе.

1) Переход на UTF-8 необходим исключительно для возможности отображения символов разных алфавитов.
Переход будет производиться планомерно. С 5.2 перевели XSLT шаблоны и Web-интерфейс, далее будет конфигурация базы по-умолчанию, и т.п.
Нужно делать осторожно, чтобы минимизировать негативные _вылезания_. Т.к. код там старый, местами кодировка может быть зашита жёстко.

2) Для возможности локализации интерфейса, в первую очередь Web.
Думаю, можно сделать некую функцию-переводчик, через которую будут выводится все фразы.
Параметром - исходная фраза на русском и язык назначения.
При отсутствии перевода - аларм, с указанием фразы.
Соответственно для локализации нужно будет заполнять словарики вида:
<string key="Добро пожаловать">
<trans lang="en" value="Welcome"/>
<trans lang="bash" value="Рахим итегез"/>
</string>
Ну и по крайней мере, можно будет самостоятельно заполнять словарь. Что достаточно несложно.
Возможно, стоит предусмотреть перевод фраз с подстановками. Например:
<string key="Добро пожаловать, ув. абонент %1">
....
</string>
Будет более удобно, в плане, что в сложных фразах иногда потребуется изменение порядка следования составляющих.
Например, в немецком отрицание стоит в конце предложения, насколько я знаю.
Т.е. если разбить фразу на кусочки "Не ходи сюда xxx договор" на переводимые кусочки "Не ходи" и "договор" - то будет плохо.

В принципе, можно попробовать для начала это в Web интерфейсе 5.2. Большой кровью не пахнет..

В очень многих фреймворках, в том числе дисктопных делается аналогично - мультиязычность идёт по словарику. Допустим, тот же QT, всё по дефолту пишется, допустим, английским. В тексте все строки для вывода обёртываются в tr( ), и под каждый язык (опционально) пишутся файлы словарные в виде
guten tag=привет
error bla bla %1 bla bla=ошибка %1 блабла
итд. и всё. в итоге если язык выставлен (вручную или ситемный взялся), то берётся соответствующий перевод по исходной фразе. если перевода нет или фразы отдельной нет, берётся просто сам её аргумент (английская фраза). всё просто, всё тупо, все счастливы. здесь придётся делать через внешний шаблон какой-то с кучей переводов, конечно, но это вполне реально.

_________________
I'm clever. I've got a computer.

Чтобы все реализовать "малой кровью" может стоит хранить там только ID-ы и их же и выводить? Да получится двойная работа - заполнять справочник в клиенте + XSL править но что поделать - нужна многоязычность - придется попотеть, опять же идея с дефолтными значениями (справочник) поможет.

Да можно русское название типа платежа переводить, по-моему..

В vBulletin есть понятие "фраза" и эти "фразы" в зависимости от выбранного юзером языка отображаются так как эта "фраза" описана для этого языка, т.е. "фраза" - это переменная которую, в БГБ, можно было бы передавать в XML в виде, например, $tariff а в XSL ей бы соответствовало "тариф" для русского и т.д. для всех возможных языков.

Большое спасибо всем кто продолжает эту тему и поддерживает меня в том, что любое современно ПО ориентированное на международный рынок должно быть на UTF-8. Тема для меня по прежнему актуальна и интересна.


Прошу прощения - никого не хотел обидеть, я думал, что за пределы вежливости не вышел... Задал вопрос на форуме именно, чтобы мнение общественности побудило разработчиков к осознанию необходимости юникода в биллинге. Если б я спросил в хелпдеске или по почте - думаю мне бы ответили: "никому кроме вас это не нужно и делать это мы не будем". Я же пытаюсь объяснить, что за пределами России есть другие страны, где тоже хотят приобрести офигенно хороший (кроме шуток) софт под названием bgbilling и пользоваться им. Думаю на доходах Вашей компании это скажется только положительно.
Почему акцентировал, что жду позиции разработчиков? Потому что без Вашей четкой позиции по этому вопросу не было бы этого обсуждения. Мне нужен был не очередной "костыль" к биллингу, а коренное решение проблемы. Думаю, я задал этот вопрос в правильной теме: "BGBilling (проект) » Разные вопросы, обсуждения и предложения"

- очень хорошее решение.

- тоже поддерживаю...

Устанавливаю биллинг (5.2) с нуля.
Может есть смысл ставить его на UTF-8?

Можете уточнить ситуацию с UTF-8 на текущий момент?
И так не хватает мультиязычности в кабинете (русский, украинский)..... С этим вопросом ничего не поменялось?

_________________
Работаем на 6.0 (Inet)
Подготовка к переходу на 6.2

в личном кабинете в 5.2 уже utf-8. мультиязычности нет и не планируется.

_________________
I'm clever. I've got a computer.