LINUX.ORG.RU

glibc strftime i18n/l10n

 , ,


0

2

Для тех, кто не в курсе:

strftime — POSIX-функция, которая форматирует даты и времена. Например, strftime( ..., «%d %B %Y», ...) даёт «17 January 2016» (%d — день месяца, %B — название месяца, %Y — год). Результат зависит от текущей локали, в локали ru_RU будет что-нить типа «17 Январь 2016».

Здесь есть проблема: strftime фигово интернационализирована и локализирована. «17 Январь 2016» выглядит кривенько, лучше было бы «17 января 2016».

«Поиграть» с strftime можно из командной стороки:

$ date +"%d %B %Y"
17 January 2016

$ LANG=ru_RU.UTF-8 date +"%d %B %Y"
17 Январь 2016

На эту тему в глибсишном трекере идёт базар. Коротенько тред заключается в следующем: есть предложение реализовать в глибц бсдшный костыль (%OB обозначает название месяца в родительном падеже: «%d %OB %Y» — «17 Января 2016»), я же пытаюсь пропихнуть идею что должна быть возможность получить название месяца (или дня недели) в *любом* падеже.

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

★★★★★

Последнее исправление: debugger (всего исправлений: 2)
Ответ на: комментарий от hippi90

Но зачем?

? Чтоб было.

Я сам пользую локаль en_RU и от кривой локализации не страдаю, но очень многие домохозяйки и лоровские нинужнисты пользуют локаль ru_RU. Какой-нить почтовый клиент может использовать фразу «Messages sent in %B» (e. g. «Messages sent in January»). В русской локали такая фраза будет выглядеть «Письма отправленные в Январь» (или «Письма отправленные в Января»). На лоровских нинужнистов мне насплевать, но русскоязычных домохозяек жалко.

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

debugger wrote:

Если у вас проблемы с английским, то пишите сюда.

anTaRes wrote:

«прошло 2016 Январей» :)
нинужно

Я не понял, у тебя проблемы с английским или просто словесный понос?

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

* Ъ
* если у каких-то почтовых клиентов проблемы с локализацией, то это проблемы этих почтовых клиентов, пытайся пропихнуть идею туда
* а если они делают локализацию, то делают либо простой массив замены «Январь»->«Января», либо сразу прописывают нужные варианты переводов в нужных местах, но никак не «Messages sent in %B», т.к. тогда будет тупо «Messages sent in Январь»
* кому нужна фича, которая ведет себя по разному в разных версиях/системах? разве что у себя дома в коньках я могу такое захотеть, чтоб не писать лишних 2 строчки кода для преобразования (ь->я/т->та/...)

так понятнее?

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

Идея здравая. Что с реализацией? Или ты зовешь, чтобы её написали за тебя.

По ссылке ходил? Что понял? Или ждёшь что кто-то сходит за тебя?

Языками окромя русского владеешь? Если нет, то проходи мимо.

Добавил в топикстартер ещё одну ссылку, чтоб видней было.

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

Спокойно, ты видел сколько падежей? Т.е. 6 цифрами не отделаешься. Нужно не только проживающие на СНГ, но и японцы, корейцы, финны, норвеги. Вобщем, надеюсь, что все таки твой вариант примут.

gh0stwizard ★★★★★
()
Последнее исправление: gh0stwizard (всего исправлений: 1)

Выяснил, что для японского не скланяются месяцы. Ну, это ты наверное и так знал. Если надо будет узнать что-то по японской части — обращайся.

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

Спокойно, ты видел сколько падежей? Т.е. 6 цифрами не отделаешься. Нужно не только проживающие на СНГ, но и японцы, корейцы, финны, норвеги.

Видел. Цифр жалко что-ли? А ты видел сколько «букв» в японском языке? И ничего, в юникод всё впихнули, и много чего другого, и место ещё осталось.

Если ты ходил по ссылке, то видел что моё предложение «%.#X», где # — номер падежа. В русском от 1 до 6, у хохлов от 1 до 7, в финском от 1 до 19 (если правильно помню). Хотя финн сказал что у них все месяцы имеют одно окончание поэтому им не очень нужно. Надо бы спросить его про дни недели.

Вобщем, надеюсь, что все таки твой вариант примут.

Вот и скажи это там. Хотя я предпочёл бы мнение татарина или калмыка.

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

Выяснил, что для японского не скланяются месяцы.

Японцы о себе уже позаботились. Я подозреваю, что модификаторы O и E появились с их подачи.

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

Какой-нить почтовый клиент может использовать фразу «Messages sent in %B» (e. g. «Messages sent in January»). В русской локали такая фраза будет выглядеть «Письма отправленные в Январь» (или «Письма отправленные в Января»).

А, это разумно.

Но, ИМХО, эта проблема должна решаться в библиотеках для локализации. Например, в gettext. Это лучше, чем вносить несовместимые расширения чем в стандартную библиотеку C.

Хотя, конечно, для совместимости с существующим софтом проще сделать это в glibc.

Отмечу, что ICU поддерживает ряд особых директив форматирования для дат. Там есть «название месяца в году» (в русском вроде получается родительный падеж), но в произвольном падеже месяцев там нет. В CLDR тоже есть названия месяцев в году (для русского — в род. падеже), но в других падежах нет.

proud_anon ★★★★★
()

В казахском особо такой проблемы нет. Т.е. если выводится 18 Қаңтар 2016, то в этом нет ошибки.

Однако прописью и в разговоре оно звучать именно по правилам падежей.

Надеюсь, что твой вариант примут. Постараюсь и на трекере отписаться по этому поводу.

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

Надеюсь, что твой вариант примут. Постараюсь и на трекере отписаться по этому поводу.

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

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

  • покажите мне псевдокодом как после изменения должен будет выглядеть этот код: «Messages sent in %B» ? Допустим я фин, и для меня в моей локали это должно быть ...

    «%.#X», где # — номер падежа. В русском от 1 до 6, у хохлов от 1 до 7, в финском от 1 до 19

    «Messages sent in %.18X» (например) так чтоль? как будет это выглядеть в другой локали?
  • вполне возможно что падежи в разных языках не соотв. друг-другу, т.е. вдруг у меня локаль древнерусская какая-то и мне нужно «Январем сей свиток был отправлен» или тип того
  • немного перпендикулярный взгляд на проблему: в той же $ data есть возможность указать стандарт, и получить кусок даты $ date --rfc-3339=date (например), т.е. в случае с «date» на, мой взгляд, более разумно было бы добавить еще стандартов (даты же у нас по стандартам записываются, не?) и дать возможность выбора в качестве куска «month»
    в таком случае запись «18 января 2016 года» должна будет прописываться в соотв. падеже в разных локалях, но в случае с strftime наверное букв не хватит на все эти стандарты

    но, сейчас то в i18n/l10n наверняка делают соотв. переводы для месяца, бывает по разному (в том числе как у аффтара), но обычно делают 2 «метки» для перевода %cur_month% и %in_month%, которые будут соотв. образом переведены локализатором («Январь», «в январе»)
    без участия полиглота-разработчика, пинания разрабов библиотеки, пинания админов для обновления библиотеки ...
    обычными людьми, носителями языка
anTaRes ★★★★
()
Ответ на: комментарий от proud_anon

Но, ИМХО, эта проблема должна решаться в библиотеках для локализации. Например, в gettext.

Почему это? Зачем в каждом приложении локализовывать одно и то же снова и снова? Есть механизм локалей, в локаль зашита куча информации — начиная от collate и кончая символами валют, включая как обращаться к замужним и незамужним дамам. Чего бы не расширить список названий месяцев и дней недели (который сейчас включает только названия в именительном падеже) разными падежами, и дать программистам возможность использовать эту информацию посредством strftime?

Это лучше, чем вносить несовместимые расширения чем в стандартную библиотеку C.

Опять же, есть прецеденты. Уже сейчас в глибц вообще и в strftime в частности полно гнушных расширений.

Опять же, сегодня гнушное расширение, а завтра, глядишь — стандарт. (Ну, ладно, не завтра а лет через дцать.) Есть прецеденты:

'%R'
    The hour and minute in decimal numbers using the format
    '%H:%M'.

    This format was first standardized by ISO C99 and by
    POSIX.1-2001 but was previously available as a GNU extension.

Не, я отлично понимаю мотивацию сделать это через gettext: взял и сделал в своей программе, никого не спрашивая и не ожидая нужного тебе исправления десяти лет. Но я не совершенно не согласен с мнением что это «должно» делаться через gettext: локали уже есть, strftime уже есть, но малость недоделаны, поскольку в английском языке существительные не склоняются и оригинальным англоговорящим разрабам было невдомёк что может быть иначе. И, можно сказать, дело принципа — достучаться до разрабов глибц и ISO/IEC 30112 сообщить о своих нуждах.

Посмотрите на японцев: у них принято с началом правления каждого императора начинать новую эру и заново отсчитывать года с единицы: первый год правления императора такого-то, второй год правления, и так далее. И чуваки не комплексуя по этому поводу пропихивают понятие «эра» в ISO/IEC 30112 (или в POSIX который был до него).

И теперь посмотрите на русских (и кое-каких ближайших западных соседей): название месяца в дате кривое? Говно вопрос, мы как нить перебьёмся, через gettext сделаем. Можно скостылить родительный падеж? Слава те хоспади, дай вам бох здоровья и долгих лет жизни. Не, остальные падежи нам не надоть. Мы фразу подкрутим чтоб другие падежи не пользовать. Но зачем ограничивать великий и могучий?

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

…по ссылке не ходил, почитал тему по диагонали…
…отыграю свою роль мудака до конца…
Покажите мне псевдокодом как после изменения должен будет выглядеть этот код: «Messages sent in %B» ? Допустим я фин, и для меня в моей локали это должно быть ...

Я после твоего первого сообщения тебя в игнор добавил. Так что не обижайся если я не отвечаю. Однако, вопрос твой случайно заметил. Показываю:

«Messages sent in %B» по-русски будет выглядеть «Письма отправленные в %.6B» (6 — творительный падеж в русском). По-фински это будет выглядеть так же, только на финском и цифра будет другая, соответствующая необходимому падежу названия месяца в этой фразе.

Остальное не читал, извини. Если тебе лень самому в тему въехать, не вижу смысла перед тобой бисер метать.

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

пропихивают понятие «эра» в ISO/IEC 30112 (или в POSIX который был до него).

Пример:

$ LANG=ja_JP.UTF-8 date +"%d %B %Y"
19 1月 2016

$ LANG=ja_JP.UTF-8 date +"%d %B %EY"
19 1月 平成28年

%Y — год, %EY — год в соответствующей эре. 2016 = 28 год правления императора Акихито.

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

Среднее из двух зол это libdate. Причем интерфейс можно сделать действительно удобным, в отличие от 1-2 букв/цифр. ИМХО.

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

Я после твоего первого сообщения тебя в игнор добавил. Так что не обижайся если я не отвечаю.

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

«Messages sent in %B» по-русски будет выглядеть «Письма отправленные в %.6B» (6 — творительный падеж в русском). По-фински это будет выглядеть так же, только на финском и цифра будет другая, соответствующая необходимому падежу названия месяца в этой фразе.

т.е., я так понимаю, аффтар либо сам переведет на все нужные языки, подставляя соотв. цифру, либо кинет ссылкой на ман strftime в переводчиков
зато им нужно будет перевести 1 фразу а не 13 («Messages sent in» и названия месяцев в нужном падеже)? ну-ну
кароче, в качестве примера нужности «Messages sent in %B» как-то не убедительно выглядит есть другие примеры?

anTaRes ★★★★
()

Неубедительно. anTaRes правильно отметил.

Неподъёмная ( => ненужная, FOSS генерирует мало бабла, не до этого) это задача, в каждом приложении для всех языков с падежами правильно закодить спецификаторы. Англофоны будут вообще не в курсе, русские будут кодировать свои падежи, финны - свои (если будут в курсе про твою систему). Едва ли найдётся софтина, для которой переводчики прошарят твою систему. И всё равно в ходу будет не больше пары ключевых падежей.

Нет багов (и тех. долга) только в той строчке кода, которой нет. Поэтому сокращать количество второстепенной логики в коде - благородная задача. Ради этого стоит использовать простые и нейтральные языковые конструкции.

Я после твоего первого сообщения тебя в игнор добавил.

Фу таким быть.

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

Посмотрите на японцев: у них принято с началом правления каждого императора начинать новую эру и заново отсчитывать года с единицы: первый год правления императора такого-то, второй год правления, и так далее. И чуваки не комплексуя по этому поводу пропихивают понятие «эра» в ISO/IEC 30112 (или в POSIX который был до него).

То, что они пытаются это делать, не значит, что это хорошо.

Честно говоря, я думаю, что существование локалей в каком-либо виде, кроме как простого индикатора страны, языка и некоторых других предпочтений пользователя, — это плохо. Если софт интернационализован, он должен уметь выводить данные в разных форматах сам (через библиотеку, например). Если нет, то нет ничего хорошего в «Fatal problem: файл не найден». Если не знаешь английского, то не поймёшь этого лога всё равно, а если ты отправишь его разработчикам программы как есть, они его не поймут.

А конкретно по изначальному вопросу, подумай вот о чём. Пусть наш почтовый клиент хочет написать «Письма, отправленные с августа по октябрь». Я плохо помню французский, но вроде там «с августа по октябрь» будет «d'août à octobre», а «с сентября по октябрь» будет «de septembre à octobre». «Этот сентябрь» будет «ce septembre», а «этот октябрь» будет «cet octobre». Почему? Потому что «août» и «octobre» начинаются с гласных, а «septembre» — с согласной.

Как ты предлагаешь решать эту проблему?

Ты, конечно, можешь сказать: «Ну пусть французы тогда вместо падежей впишут в свою локаль названия месяцев с разными предлогами, указательными местоимениями и так далее». Но тогда, во-первых, ты признаешь, что мы уже не склонения слов должны держать в локали (падежей во француском нет), а какую-то сложную таблицу форм слов и словосочетаний, которую лингвисты и/или переводчики софта должны хорошо продумать и составить, а потом, возможно, ещё и менять, если найдутся ошибки и неучтённые случаи. А во-вторых, я не так много языков знаю, что если есть язык, где, например, названия месяцев разного рода? Или имеют ещё какие-то разные грамматические признаки, под которые нужно нетривиальным образом подстраивать всю фразу?

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

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

То, что они пытаются это делать, не значит, что это хорошо.

Они не пытаются, они делают.

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

Не вижу противоречий: либц разве не библиотека?

нет ничего хорошего в «Fatal problem: файл не найден». Если не знаешь английского, то не поймёшь этого лога всё равно, а если ты отправишь его разработчикам программы как есть, они его не поймут.

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

И всегда можно попросить прислать нелокализованный выхлоп. Если люди хотят поиметь проблему исправленной — пришлют.

Пусть наш почтовый клиент хочет написать «Письма, отправленные с августа по октябрь». Я плохо помню французский, но вроде там «с августа по октябрь» будет «d'août à octobre», а «с сентября по октябрь» будет «de septembre à octobre». «Этот сентябрь» будет «ce septembre», а «этот октябрь» будет «cet octobre». Почему? Потому что «août» и «octobre» начинаются с гласных, а «septembre» — с согласной.

Как ты предлагаешь решать эту проблему?

Я предлагаю оставить эту проблему французам.

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

Avoid arbitrary limits on the length or number of any data structure, including file names, lines, files, and symbols, by allocating all data structures dynamically. In most Unix utilities, “long lines are silently truncated”. This is not acceptable in a GNU utility.

Надо сделать таблицу названий «резиновой», не устанавливая взятый с потолка размер 12×2 (двенадцать месяцев на два варианта).

Может, это и не спасёт французов или каких-нить полинезийцев, о которых я нечего не знаю, но это поможет, по крайней мере, славянским языкам.

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

Да, признаю. Каждый язык должен сам решить что и сколько хранить в этой таблице. Одино из возможных решений — оставить всё как было, не расширять таблицу дополнительными строчками.

Возможно, придётся менять. Но разве есть хоть что-то неизменное? Всё развивается, растёт и изменяется.

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

Неподъёмная ( => ненужная, FOSS генерирует мало бабла, не до этого) это задача, в каждом приложении для всех языков с падежами правильно закодить спецификаторы.

Не понял, это какая задача неподъёмная? Автору программы не надо кодить спецификаторы. Авторо программы кодит:

    strftime( buffer, sizeof( buffer), _( "Messages sent in %B:" ), & tm );

Усё. Далее задача локализаторов перевести «Messages sent in %B:» на родной язык. Перевод включает в себя в том числе выбор падежа. Я приводил пример перевода на русский: «Письма отправленные в %.6B:». Что тут сложного и неподъёмного?

Англофоны будут вообще не в курсе, русские будут кодировать свои падежи, финны - свои (если будут в курсе про твою систему).

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

Нет багов (и тех. долга) только в той строчке кода, которой нет.

Ясен перец. Не ошибается тот, кто ничего не делает.

Фу таким быть.

? Ты спрашиваешь у прохожего «Как пройти в библиотеку?» и получаешь ответ «нинужно» — в чём смысл выслушивать его дальнейшие изречения? Идешь себе дальше, спрашивая у более адекватных прохожих.

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

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

Ты сейчас проявляешь тот же менталитет, благодаря которому мы получили механизм локалей и все связанные с ним проблемы. «Оставим каждой стране решать свои проблемы самостоятельно». Но в свободном софте при существующем уровне глобализации все проблемы становятся общими.

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

Почему это? Зачем в каждом приложении локализовывать одно и то же снова и снова? Есть механизм локалей, в локаль зашита куча информации — начиная от collate и кончая символами валют, включая как обращаться к замужним и незамужним дамам.

В следующем своём сообщении я стал объяснять, почему. И на него ты ответил:

Я не утверждаю что моё предложение подходит всем языкам.

Но, тем не менее, остаёшься при мнении, что это решение — нечто большее чем временный хак для отдельных языков, пока не появится универсальное решение?

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

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

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

Во-вторых, локали неплохо справляются со своей задачей, а связанные с ними проблемы возникают потому, что мы хотим (ок, «я хочу») от них большего. Раньше увидеть «16 Январь 1996» уже было достижением и счастьем, теперь же «16 Январь 2016» вызывает неудовольство. Это нормально. Или ты имеешь ввиду какие-то другие проблемы, связанные с локалями?

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

Вспомни историю с кодировками, например. Сначала америкосы сделали себе семибитную кодировку и были счастливы. По мере распространения компьютеров возникла нужда в символах с «мозгоглюйками» (á, à, etc) — сделали восьмибитную кодировку. Грекам были нужны греческие буквы, русским — русские, каждый хачил вторую половину кодовой таблицы как хотел, не сильно оглядываясь на соседей. Только русских кодировок было несколько штук. Простой текстовый файл, в котором сочетались бы французский, греческий и русский был просто невозможен. (Ты помнишь chiwriter?) Азиаты (китайцы, японцы, у кого там ещё иероглифы") придумывали свои хитрожопые кодировки. Сколько лет потребовалось для создания юникода? И сколько версий юникода было выпушено? Если посмотреть на его историю, то увидишь интересные вещи: в стандарт то добавляли символы, то убирали их, то добавляли снова. Короче, мораль: Москва не сразу строилась.

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

Гм, э… откуда такая уверенность что ты знаешь «самое верное решение»? И в чём конкретно оно, это самое верное решение, состоит? Чем новая версия strftime будет лучше старой? Например, как новая версия strftime будет решать «французскую проблему»? Чем новая библиотка лучше существующей?

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

Но, тем не менее, остаёшься при мнении, что это решение — нечто большее чем временный хак для отдельных языков, пока не появится универсальное решение?

Универсальное решение может никогда не появиться. Я вообще не уверен что оно возможно. И да, я остаюсь при мнении, что моё предложение лучше того, что пытаются пропихнуть поляки. А уж как моё предложение называть — вопрос философский. Пусть будет «временный хак». В конце концов, в этом мире всё временно.

debugger ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.