Вопрос о разделителях
Друзья! Ситуация следующая: Импортозаместили ПО, все работает, система на этапе приемочных испытаний. Но, возникла Заказчица со своими хотелками, которые заключаются в следующем: Система генерирует отчеты, где разделители дробных чисел представлены точками, т.е. согласно негласным американским правилам, а она хочет запятые, как типа принято в России. О том, что, ни один стандарт не запрещает использование на территории РФ точки в документах, БД, экранных формах и т.д. слышать не хочет. Поэтому вопрос - какие проблемы теоретически могут возникнут, если придется переходить на запятые? Меня сейчас интересует взгляд со стороны разработчика, который столкнулся бы с подобной проблемой. Времени в обрез, программисты крутят у виска, дама стоит на своем, сроки проекта ограничены, в целом и штрафы могут прилететь. Что делать, у кого какие идеи. И, второй вопрос - есть ли какие-то международные стандарты, которые устанавливают правила применения типов разделителей? Или данные хотелки должны быть указаны в ТЗ? У меня сейчас один вариант - давить на то, что данные требования не были заявлены Заказчиком в ТЗ, а четких стандартизированных правил на этот счет не существует.
Открываешь букварь и читаешь про локализацию.
Например ToString(IFormatProvider):
decimal value = -16325.62m;
// Display value using the invariant culture.
Console.WriteLine(value.ToString(CultureInfo.InvariantCulture));
// Display value using the en-GB culture.
Console.WriteLine(value.ToString(CultureInfo.CreateSpecificCulture("en-GB")));
// Display value using the de-DE culture.
Console.WriteLine(value.ToString(CultureInfo.CreateSpecificCulture("de-DE")));
// This example displays the following output to the console:
// -16325.62
// -16325.62
// -16325,62
Что делать
Уволить нахрен криворуких программистом и нанять тех, которые умеют разрабатывать многоязычные приложения.
у кого какие идеи.
Если уволить криворуких нельзя, то дать им ссылку на MSDN пусть учатся.
есть ли какие-то международные стандарты, которые устанавливают правила применения типов разделителей?
Нет, нету. В каждой стране свои правила. И точка или запятая в числах - это ваша не единственная проблема. Вот когда дойдете до дат - это будет веселье:
using System;
using System.Globalization;
public class Example2
{
public static void Main2()
{
CultureInfo[] cultures = new CultureInfo[] {CultureInfo.InvariantCulture,
new CultureInfo("en-us"),
new CultureInfo("fr-fr"),
new CultureInfo("de-DE"),
new CultureInfo("es-ES"),
new CultureInfo("ja-JP")};
DateTime thisDate = new DateTime(2009, 5, 1, 9, 0, 0);
foreach (CultureInfo culture in cultures)
{
string cultureName;
if (string.IsNullOrEmpty(culture.Name))
cultureName = culture.NativeName;
else
cultureName = culture.Name;
Console.WriteLine("In {0}, {1}",
cultureName, thisDate.ToString(culture));
}
}
}
// The example produces the following output:
// In Invariant Language (Invariant Country), 05/01/2009 09:00:00
// In en-US, 5/1/2009 9:00:00 AM
// In fr-FR, 01/05/2009 09:00:00
// In de-DE, 01.05.2009 09:00:00
// In es-ES, 01/05/2009 9:00:00
// In ja-JP, 2009/05/01 9:00:00
Или данные хотелки должны быть указаны в ТЗ?
По идее используемые стандарты, конечно, можно перечислить в ТЗ... Но если заказчик из конкретной страны, то он по умолчанию будет ожидать, что тексты, числа, даты и прочие локализируемые штуки будут показаны на его языке.
У меня сейчас один вариант - давить на то, что данные требования не были заявлены Заказчиком в ТЗ, а четких стандартизированных правил на этот счет не существует.
Гугли ГОСТы.
Уволить нахрен криворуких программистом и нанять тех, которые умеют разрабатывать многоязычные приложения.
Не возражаю :)
Гугли ГОСТы
Иногда даже просто википедии достаточно
В общем ТСу стоит не выёживаться, а радосто помахивая хвостом быстренько перейти на запятые. Поругаться с заказчиком, конечно, дело благородное, но...
ТС может сослаться на ГОСТ 6.20.1—90 (в качестве десятичного разделителя допускает запятую и точку) но закачик побьёт его ГОСТ 1.5-2001 («Стандарты межгосударственные, правила и рекомендации по
межгосударственной стандартизации. Общие требования к построению,
изложению, оформлению, содержанию и обозначению»)
запрещает
использование точки в качестве разделителя десятичной дроби (пункт
4.15.2 «При записи десятичных дробей не допускается заменять точкой
запятую, отделяющую целую часть числа от дробной.»)
Импортозаместили ПО, все работает, система на этапе приемочных испытаний.
Надо бы добавить "у меня на ноутбуке все работает", тогда это 100% что все придется перепроверять и переделывать.
Что делать, у кого какие идеи.1. Поменять locale на нужную
2. Поменять значение переменной decimal_separator=","
3. Найти чела, который разбирается в управлении проектами и быдлокодерами
4. Уволиться
Я так понимаю кучка быдлокодеров решила срубить бабла по легкому, сделала
продукт для левой страны с неправильной локализацией (почему не для
Гондураса?), а теперь быкует и ищут какие-то отмазки, начиная "на моем
ноутбуке все работает" и "в ТЗ этого не написано" и заканчивая
"декларацией прав человека" и "международными соглашениями".
Так, они пошли по самому простому пути - максимально скопировали буржуйскую разработку. Ну, а там точки в качестве разделителя.
Ладно, будем додавливать разработку, исправить все это, как я поняла, не проблема.
Но, здесь и такой момент - стандарт таки не запрещает использование точки, да и буржуйская система их до этого устраивала.
ТС, делать локализованный вывод чисел, дат, валют и прочего - на экран, печать и т.д.
Уволить нахрен криворуких программистом и нанять тех, которые умеют разрабатывать многоязычные приложения.
Локализованный вывод - не пряморучие, а какие-то прямо азы. Даже джуны умеют делать локализованные приложения. Тут скорее просто забили при разработке (локализация не была в ТЗ), или, как уже сказал ТС выше - забили при копировании чужого кода.
Поэтому вопрос - какие проблемы теоретически могут возникнут, если придется переходить на запятые?
------
Интересный вопрос.
У меня есть почти такой же - есть большое и серое - что делать если или когда его встречу?
На последнем месте работы в чуть более сложной ситуации был написан отдельный IFormatProvider.
Но там было очень далеко от используемых стандартов.
исправить все это, как я поняла, не проблема.
Исправлять - нудная и рутинная работа. Нужно буквально вручную перебирать весь код, где какой-то вывод (на экран, печать и т.д.) присутствует. А для этого нужно знать, где конкретно присутствует вывод, чтобы не лопатить весь код. Автоматически - навряд ли. Будет много ошибок и много чего ускользнёт, а потом всё равно придётся вручную всё проверять... Хотя, теоретически, если весь вывод был реализован через какой-то единый интерфейс или базовый класс... Но ведь ТЗ на локализацию изначально не ставилось? Так что навряд ли так было реализовано.
программисты крутят у виска
Мозги программистов устроены иначе чем у нормальных людей, поэтому им нужно 100% техническое задание.
Пример задачки: "Создаём 10 кошельков, подсчитываем на какой кошелёк за сутки упало больше тысяч евро..."
Сейчас обозреватели отдают мне CSV файлы, где по америконски - разделитель - запятая!!! а числа с точками,
тоесть когда я открою с офисом, с точками не смогу сортировать по возрастанию, не увижу сколько миллионов за день заработал!
Я делаю так, открываю в текстовом эдиторе, меняю запятые на семикулон, точки меняю на запятые, и всё начинает работать,
но зачем мне лишние телодвижения? открывать менять разделители, сохранять, если мне будут писать софт на заказ? 
Вопросы и Ответы - Программируем калькулятор пособий для беженцев вместе.
ГОСТ 1.5 распространятся исключительно на Стандарты, как документ. А ГОСТ 6.20.1 сейчас гляну, спасибо.
А чо это все "программисты" советуют вам ГОСТом перед носом помахать, это что госзаказ?
Шутка в тему, Рофлящие с госуслуг никогда не работали в продакшене. Проще отработать 1000 авторизаций, чем 100000 запросов к API на очередь - грамотное решение: https://coub.com/view/2tt2hf
Вопросы и Ответы - Программируем калькулятор пособий для беженцев вместе.