Если вам приходилось иметь дело с кубом, в котором число мер и измерений over9000 и не хватает трех экранов, чтобы это уместить, то, наверняка, приходилось слышать и стоны пользователей, на тему неудобства работы с этим чудовищем. Ведь пользователи чаще всего работают с одними и теми же измерениями, без которых не обходится почти ни одна выборка. Однако из-за особенности экселя, любящего сортировать по алфавиту все элементы, находящиеся в области Поля сводной таблицы, эти наиболее востребованные объекты часто разбросаны по всему списку, вперемешку с остальными (редко используемыми) элементами.


Приходится десять раз скролить список вверх и вниз, пока пытаешься установить фильтр на трёх (Дата, Товар, Клиент) полях. Работать с этим каждый день никаких нервов не хватит.

Решение банальное и не новое — в начале имен измерений добавлять символ или цифру, влияя тем самым на порядок.

Но пользователи — это одна сторона медали, им такой подход удобен. А как же разработчики?
Ведь оно как должно быть: начинаешь писать в формуле имя измерения, а студия подсказки выдает, верно? Вот только в случае с допсимволами все это выглядит в коде, скажем так… не очень. В VS2017 уже сделали поиск по вхождению, а в предыдущих такого не было и приходилось писать Календарь не с буквы К, а с цифры 5, потому что 5 Календарь. Запросы в других программах приходится писать без подсказок и упомнить какая цифра у какого измерения или поля — тот еще квест.



Когда нужно изменить порядок, то, по сути, нужно переименовать таблицу или поле, а если это поле используется в формуле, то студия исправит и формулу. Когда формул десятки (а их всегда десятки), то в Git будет подсвечиваться половина модели, потому что студия реально все формулы исправила, в то время как я хотел только поменять поля местами в порядке сортировки. Запросы же в других источниках (за пределами студии) поломаются вообще. Крайне неудобно!

Но выход есть.

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

Перевод осуществляется путем выгрузки из .bim-модели файла .json с текстом, его редактированием и последующей загрузкой обратно в модель. Но Visual Studio не позволяет выгрузить файл для русского языка, если модель изначально русская (в общем, для базового языка модели перевод выгрузить нельзя). Но можно выгрузить любой другой!



Выгруженный файлик нужно отредактировать, с помощью любого текстового редактора, поддерживающего юникод, заменив в нем en-US на ru-RU.

Далее с помощью специальной программы SSAS Tabular Translator отредактировать названия (но можно и в блокноте, если хотите, — дело хозяйское).



Импортируем наш файл обратно в проект



Вуяля



У перевода есть еще один существенный плюс:

Из файла .json в модель загружаются только измененные (переведенные) строки, а не целиком весь файл, и хранится только перевод. Поэтому даже если появится новое измерение или мера, а вы забудете ее «перевести» — ничего не поломается, она просто будет отображаться в экселе как есть.

Можно, конечно, не делать все эти манипуляции с подменой en-US на ru-RU, но тогда пользователям придется перенастроить подключения к источнику данных, добавив опцию локали английского языка.

Есть особенность

После того, как мы добавим в модель перевод для базового языка, его нельзя будет удалить без предварительной подготовки.



Скорее всего, это вряд ли понадобится, но, как известно, если нельзя, но сильно хочется, то можно.

Открываем Обозреватель решений, щелкаем правой кнопкой по .bim-файлу модели и выбираем пункт Перейти к коду



В коде ищем строчку ru-RU, но не ту, что в начале файла, а ту, что ближе к концу, и исправляем на en-US





Исправляем, сохраняем, переоткрываем модель в режиме конструктора и проверяем



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