LINUX.ORG.RU

Кодировка консоли для разработки

 ,


0

3

Дистрибутив Fedora, стоит русская кодировка консоли locale

LANG=ru_RU.UTF-8

LC_CTYPE=«ru_RU.UTF-8»

LC_NUMERIC=ru_RU.UTF-8

LC_TIME=ru_RU.UTF-8

LC_COLLATE=«ru_RU.UTF-8»

LC_MESSAGES=«ru_RU.UTF-8»

LC_PAPER=ru_RU.UTF-8

LC_IDENTIFICATION=«ru_RU.UTF-8»

.. и т.д.

Периодически разрабатывается что то на C/C++ как из консоли так и из под разных IDE. При ошибках получаем что типа

../src/fix.cpp:32:48: ошибка: expected unqualified-id before «-» token

../src/fix.cpp:32:49: ошибка: нет декларации «toString» в этой области видимости

make: *** [src/subdir.mk:26: src/fix.o] Ошибка 1

т.е ошибки на русском. Можно как то весть toolchain C/C++ принудительно завести на сообщения на EN?

ошибка: expected unqualified-id before «-» token

Сдаётся мне, что это сообщение тупо не перевели. Т.е. в файле /usr/share/.../locale/ru/LC_MESSAGES/gcc.mo (ну или где он там лежит) тупо нету перевода этого сообщения и берётся дефолтное английское сообщение.

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

WatchCat ★★★★★
()
export LANG="en_US.utf8"
export LC_CTYPE="ru_RU.utf8"
export LC_NUMERIC="ru_RU.utf8"
export LC_TIME="en_GB.utf8"
export LC_COLLATE="ru_RU.utf8"
export LC_MONETARY="en_US.utf8"
export LC_MESSAGES="en_US.utf8"
export LC_PAPER="ru_RU.utf8"
export LC_NAME="en_US.utf8"
export LC_ADDRESS="en_US.utf8"
export LC_TELEPHONE="en_US.utf8"
export LC_MEASUREMENT="en_US.utf8"
export LC_IDENTIFICATION="en_US.utf8"

чтобы даты и единицы измерения были человеческими, а не имперскими.

soomrack ★★★★★
()
Последнее исправление: soomrack (всего исправлений: 1)
Ответ на: комментарий от soomrack

чтобы даты и единицы измерения были человеческими, а не имперскими.

Вот это:

export LC_MEASUREMENT=«en_US.utf8»

Приведёт к тому, что температуры и расстояния начнут отображаться в идиотских устаревших единицах (типа, «10 ладошек, 5 пальцев»). Нафига?

Chiffchaff
()
Ответ на: комментарий от firkax

Где в gcc температуры и расстояния?

В gcc их может быть и нет. Тем более, повод не трогать LC_MEASUREMENT, чтобы случайно не получить средневековые измерения в локтях, шагах и мизинцах в какой-нибудь другой программе.

Chiffchaff
()
Ответ на: комментарий от Chiffchaff

Возможно.

Ну, в любом случае, самое простое это поставить LANG= (пустая строка), если ты больше ничего не настраивал то этого достаточно для отключения всех локализаций т.к. переменные LC_ дефолтно тоже пустые.

firkax ★★★★★
()

Предлагаемый вариант типа export LANG=«en_US.utf8» он решит проблему в конкретном дереве процессов. А у нас целый выводок тулзов gcc -> /usr/bin/gcc make -> /usr/bin/make ide1 -> … и т.д. Предлагается обернуть каждый /usr/bin/gcc в свой bash-ик с export? Оно конечо получится, и через выявления все новых и новых бинарников и создания bash оболочек. Но выглядит как то не очень. Хочется решение по «управлению локалью» конкретного бинарника. Да и есть подозрение что особо умные скрипты и IDE возьмут и вызовут по полному пути /usr/bin/gcc вместо gcc и все вариант с export-оболочками не проходит.

Zoonoid
() автор топика
Ответ на: комментарий от Chiffchaff

Ну на русском ошибки - и что? Каким образом, это представляет проблему?

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

monk ★★★★★
()

Можно как то весть toolchain C/C++ принудительно завести на сообщения на EN?

Перейти на Gentoo и создать свой список приложений, собирающихся с отключённой локализацией.

annulen ★★★★★
()
Ответ на: комментарий от anonymous

export LANGUAGE=en

О, вот это интересный момент. На кой чертов бешенный ляд, эти наркоманы ввернули ДВЕ переменные окружения LANG и LANGUAGE для одного и того же? Что за гребанный дебильный бред.

James_Holden ★★★★★
()
Ответ на: комментарий от James_Holden

Совет с export LANGUAGE=en оказывается наиболее стойким ко всяким хитрожопым вызовам и запускам. Наверное даже более того, вот этот export LANGUAGE=en надо прикрутить прямо при старте терминала что вы все графические терминалы были чисто английскими. Народ попробует потестить еще что из этого получается, но видится как решение проблемы. А так все стандартное с графикой браузеры, всякие офисы остаются на русской локале.

Zoonoid
() автор топика
Ответ на: комментарий от Chiffchaff

Приведёт к тому, что температуры и расстояния начнут отображаться в идиотских устаревших единицах (типа, «10 ладошек, 5 пальцев»). Нафига?

Вот зря «устарели» - раньше хоть понятно было, поместится твоя пятая точка в кресло или нет. А сейчас сантиметры двигают туда-сюда и в результате в самолетах летаешь в позе Зю, как заядлый йог… Раньше конструировали для живых людей, а сейчас экономят на материалах и размерах так, что непонятно на кого оно вообще рассчитано. В результате комфорта жизни нет.

necromant ★★
()
Ответ на: комментарий от necromant

Я не уверен, что в самолётах, построенных в стране, где длину измеряют локтями, вершками, пальцами, расстояние между креслами больше. Мне вообще, кажется, что это не связано.

Хотя, наверное, нагляднее, когда они решают ещё ужать салон: «Для увеличения вместимости и доходов, расстояние до передней спинки уменьшает с двух лаптей до трех средних пальцев»… Нагляднее, наверное, чем в сантиметрах, но всё равно - отказать.

Chiffchaff
()
Ответ на: комментарий от James_Holden

Потому, что LANG задаёт один язык, а LANGUAGE - список языков. В первом случае откат всегда идёт на английский язык, если перевода на целевом языке не найдено. Во втором случае откат идёт по списку заданных языков. К примеру если ты выставишь LANGUAGE=sv:de то будет выполняться перевод на шведский язык, а откат будет на немецкий. С LANG такую логику реализовать не получится.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от James_Holden

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

vbr ★★★★★
()
Ответ на: комментарий от vbr

Все, это разговор слепого с глухим. Я не знаю как еще объяснить простое предложение на русском языке.

Да как угодно, при помощи двоеточия например. Ну сделали бы эти юникс-вытираны древние, LANG где задается список локалей а не одна локаль, и все. Весь софт потом бы написали с учетом этого. Зачем они вторую переменную ввели?

Почему переменная называется LANGUAGE, это единственное число, а суть в том что можно задать список? Список это множественное число. Это явная глупость сплошная.

James_Holden ★★★★★
()
Ответ на: комментарий от vbr

И я не просто так подрываюсь от этой фигни. Был в GIMP многолетний баг, из-за которого он неправильно выбирал локализацию интерфейса. Этот баг дико бесил многих людей. Я потратил кучу времени, чтобы отловить проблему в исходниках GIMP.

Проблема, оказалась крайне проста. Половина кода и библиотек этой ереси, читала переменную LANG, а вторая половина LANGUAGE. При этом, в коде GIMP задавалась только LANG для выбора языка. В результате локализация шла по одному месту. Много-много лет.

James_Holden ★★★★★
()
Ответ на: комментарий от James_Holden

Да как угодно, при помощи двоеточия например.

И это сломает весь софт.

Ну сделали бы эти юникс-вытираны древние, LANG где задается список локалей а не одна локаль, и все.

Они не сделали, всё, проехали, это уже история. gettext писался гораздо позже, чем придумали локали.

Весь софт потом бы написали с учетом этого. Зачем они вторую переменную ввели?

Кто «они»? Авторы gettext не хотят переписывать весь софт. Авторы всего софта тоже не хотят его переписывать. Авторы gettext пишут свою библиотечку и всё, это их предел. Для своей библиотечки они придумали переменную LANGUAGE, как способ расширенной конфигурации.

vbr ★★★★★
()
Ответ на: комментарий от James_Holden

Проблема, оказалась крайне проста. Половина кода и библиотек этой ереси, читала переменную LANG, а вторая половина LANGUAGE. При этом, в коде GIMP задавалась только LANG для выбора языка. В результате локализация шла по одному месту. Много-много лет.

gettext поддерживает обе переменные.

vbr ★★★★★
()
Ответ на: комментарий от soomrack

export LC_NUMERIC=«ru_RU.utf8»

А какой-нибудь шибко умный софт не попытается в этом случае десятичную точку на запятую поменять? Особенно хорошо это смотрится в файлах где запятая является разделителем,например csv.

Я вот посмею утверждать,что из всей «русификации» реально нужно только вот это:

export LC_CTYPE="ru_RU.utf8"
export LC_COLLATE="ru_RU.utf8"

Чтобы сишная библиотека понимала что русские буквы это тоже буквы.

watchcat382
()
Ответ на: комментарий от Chiffchaff

Ну на русском ошибки - и что? Каким образом, это представляет проблему?

Перевод там бывает такой что приходится напрягать мозг чтобы понять что же это в английском оригинале было. Да и гуглить ошибки на английском куда как эффективнее.

watchcat382
()
Ответ на: комментарий от watchcat382

Проблема плохих переводов ушла уже лет 20 как.

К тому же, оно всё обычно в открытом доступе: легко получить доступ к переводам и поправить их. Я не сосчитать сколько раз правил, в последнее время только редко, потому что почти везде уже из коробки нормальные.

Chiffchaff
()
Ответ на: комментарий от Chiffchaff

К тому же, оно всё обычно в открытом доступе: легко получить доступ к переводам и поправить их

Вот только при каждом апдейте файлы перезаписываются дистрибутивными и надо снова править. Раз так на третий-пятый становится Лень. Проще один раз английские сообщения включить и не мучаться.

watchcat382
()
Ответ на: комментарий от watchcat382

Я имею в виду поправить переводы в апстриме проекта.

У почти любого проекта сейчас используется какой-нибудь облачный сервер для переводов, достаточно обычно написать мейнтейнеру и попросить в него доступ, чтобы исправить ошибку раз и навсегда для всех.

Chiffchaff
()
Ответ на: комментарий от Chiffchaff

достаточно обычно написать мейнтейнеру

Обычно примерно с тем же успехом можно написать господу Богу. За много лет в линуксе у меня был ровно один случай когда удалось поправить глюк в апстриме (не перевод,глюк был в коде).

watchcat382
()
Ответ на: комментарий от watchcat382

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

  1. На то, баг это или не баг
  2. На его важность
  3. На оформление кода

И даже при всём при этом, мне удавалось вносить правки в 75% случаев.

Поправить переводы в разы проще, потому что за очень редким исключением, возражений к правке нет. Мантайнер не знает язык, или у него нет возражений к поправке, т.к. это не код.

Chiffchaff
()
Ответ на: комментарий от Chiffchaff

Мантайнер не знает язык

И это тоже проблема. Я например не настолько силён в деловом английском чтобы свободно переписку на нем вести и таки убедить оппонента что надо внести мои изменения. Хотя я согласен что с переводом это наверно было бы проще чем с кодом.

Отдельный вопрос,что на мой взгляд выучить английский в достаточном объеме чтобы понимать сообщения об ошибках без перевода - попроще будет. Это же не деловая переписка с ее тонкостями смысла.

watchcat382
()