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

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

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

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

При вызове тулчейна указывай другую локаль, в чём проблема?

C.UTF-8 же

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"

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

LANG=en_US someprog уже предлагали? Читаю дальше :)

В некоторых дистрибутивах есть ещё en_DK.UTF-8 с нормальными единицами и датами.

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

Вот это:

export LC_MEASUREMENT=«en_US.utf8»

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

так борода и свитер отрастут.

Чтобы выключить перевод в приложении, которое пользуется GNU gettext, достаточно задать переменную окружения LANGUAGE:

export LANGUAGE=en

о, не заметил. спс.

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

Всё ещё проще - «C» или "".

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

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

Возможно.

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

Предлагаемый вариант типа 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-оболочками не проходит.

А в чем вообще проблема изначально?

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

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

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

За локаль сообщений отвечает переменная окружения LC_MESSAGES.

Давно уже пора переходить на Rust.UTF-8. Ну или если это слишком модно-молодёжно, то можно на C++.UTF-8.

Установка export LC_MESSAGES=«en_US.utf8» не избавляет от сообщений об ошибках ../src/bl.cpp:32:49: ошибка: нет декларации «toString» в этой области видимости

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

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

export LANGUAGE=en

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

export LANG=en_US.utf8

Потом из этой консоли, запускаешь IDE и вуаля.

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

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

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

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

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

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

Я понимаю что они работают по-разному, вопрос же совсем не в том был. Зачем две, это все можно было реализовать одной переменной.

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

Ты не понимаешь о чем я, ладно, забей.

Ну объясни, как с помощью переменной LANG указать два и более языков?

через запятую епта

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

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

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

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

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

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

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

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

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

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

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

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

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

export LC_NUMERIC=«ru_RU.utf8»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Избавляет, ты врёшь.