Comments 17
Серый экспорт.
Автор великолепен! И во всем прав. Я, правда, дочитал только до идеи наказывать за "принудительную руссификацию" и дальше читать не стал. Поскольку и так прекрасно. Учитывая сколько имеется на свете языков — программистов можно наказывать непрерывно. А если добавиться всяческие диалекты и местные наречия... М-м-м!.. Лепота.
Предлагаю создать публичные лобные места и сечь их, сечь, сечь...
Или автор имел ввиду только русский? Но и тогда всё неплохо. Взять хоть программистов 1С. Необъятный источник для БДСМ.
А вообще очень плохо, когда у человека проблемы с английским на базовом уровне. Если вы не можете по-английски расписать в исходнике зачем вы использовали в коде какой-то счетчик или с какой целью поставили заглушку, то и программист из вас сомнительный. Почему? Да потому что классы, переменные и методы у вас будут называться так же.
Как бы сильно большая разница между написать название переменной/метода и написать текст, который описывает что метод делает. Тут очень разный уровень английского используется.
Я бы не согласился с таким утверждением. По причине того, что нынче считается, что если класс и метод названы правильно, то в общем отдельно объяснять смысл и не нужно. А если и нужно, то описать требуется только очень специфические моменты. Ну, например, нынче вполне конвенционально назвать метод testFunctionThrowsExceptionWhenParameterIsEmpty Какой еще дополнительный уровень знания языка тут нужен? Допустим, надо пояснить, что для PHP '0' не должно рассматриваться как пустое. /* Expects '0' is not empty */
Ну разве что подразумевается что всё описание работы метода нужно запихивать в название метода. Тогда ДА, уровень знания нужен один и тот же.
Если имеется ввиду что надо как-то описать очень сложную внутреннюю логику, то тут кажется, что придется прибегнуть к сложным оборотам. Я понимаю о чем речь. Так часто получается, когда нужно задокументировать старый код. Но опять же по современным канонам, получается так, что это проблема скорее самого метода, значит его можно разложить на куски попроще. Либо техническое задание страдает какими-то изъянами. С другой стороны, раз этот метод уже введен в эксплуатацию и он энное время уже и так работает без документации, то надо ли вообще его документировать сейчас? )
Надо! Потому что зачастую приходится каждый раз заново разбираться как этот метод работает. Не говоря уж о том, что зачастую практика с канонами не дружит. И не потому что разработчик их не знает, а потому что "сделать нужно быстро и желательно ещё вчера". Поэтому вставляется костыль. И простым названием метода/переменной этот костыль зачастую сложно описать. Да ещё на неродном языке.
А кто оплачивать поддержку локализации будет, если это не надо заказчику? Это увеличивает объем тестирования, в каких-то случаях будет тратится больше времени на проработку интерфейса, чтобы он выглядел удобным на разных языках. Да и опять же больше вводить текста и не забывать вносить изменения во все языковые ресурсы. А если только предусмотреть возможность смены ресурсов, то сильно проще провести локализацию на другой язык не будет, так как весь интерфейс может или разъехаться или будут пустые огромные пространства. К тому же, для локализации нужен человек которые не просто знает этот язык, а знает его в нужной предметной области, разработчики такими, чаще, не являются. Да и терминологии на родном языке в нужной предметной области могут не знать, чего уж там, но правильный текст будет прописан в задании или на приемке заказчик поправит.
А что касается документации, комментариев и кода. На родном языке читать документацию проще. И в этом плане жаль, что не все компиляторы пропустят не ASCII символы как код. Тут остаётся немного позавидовать тем, кто использует латиницу - они могут и имена сущностям в коде давать на родном для них языке.
Код и внутренняя документация - для тех кто участвует в разработке и сопровождении. И документацию к программе, комментарии к коду и код могу читать не только разработчики, но и команда тестирования, прочие технические специалисты занимающиеся поддержкой и установкой. И им точно удобнее читать на родном языке.
Если есть возможность обеспечить внутри компании поддержку одной локали без снижения производительности всех сотрудников задействованных в разработке, поддержке, сопровождении и эксплуатации - это же прекрасно. Это упрощает коммуникации, упрощает разработку. Удобно же когда житель Германии столкнувшись с ошибкой в программе видит ошибку на немецком, а тестировщик или специалист по сопровождению открыл документацию или код и легко может понять, что происходит, ведь все описано на, родном, немецком языке. Там где поддержка нескольких языков нужна, она есть, но не надо тащить её туда где этого не требуется.
Если говорить о сайтах, то если сайт рассчитан на внутренний рынок, то снова не надо тратиться на поддержку нескольких языков. Это дорого и не даст прибыли. Сайт для разных стран - это не просто перевести весь текс на другой язык, надо так же учитывать культурные особенности. Это и используемые изображения, расположение элементов управления, так же может меняться в зависимости от того откуда пришел пользователь. Это если сайт насчитан на разные страны. А если нет и просто случайный пользователь забрел полюбопытствовать, то браузеры вполне ему помогут переведя текст на удобный ему язык. Далеко не всегда хорошо, но в целом - сносно, найти то за чем пришел можно.
Речь не о создании программ которые уже локализованы под все языки. Речь о том что бы просто предусмотреть такую возможность в будущем. Тем более что делается это совершенно просто с помощью соответствующих библиотек. Надо лишь соблюсти ряд вышеописанных условий.
На родном языке читать документацию проще.
Сомнительное заявление. Проще для кого опять же? Я говорю о подходе в принципе. Надо смотреть на мир чуть шире.
Там где поддержка нескольких языков нужна, она есть
А в какой момент у нового проекта наступает нужность добавления других языков? Кто вообще может узнать и заинтересоваться вашей библиотекой или фреймворком зарубежом, если никто просто не может понять что это?
Речь о том что бы просто предусмотреть такую возможность в будущем. Тем более что делается это совершенно просто с помощью соответствующих библиотек. Надо лишь соблюсти ряд вышеописанных условий.
Даже просто поддержка разных локалей, без перевода, требует времени - надо переключить локаль и проверить, что даты и числа стали в соотвествии с локалью. А тут еще помнить и проверять, не сломали ли, что весь текст хранится в ресурсах и берется от туда. Это требует времени. Точно так же, как нет смысла без необходимости пытаться поддерживать все платформы. Нужно считать затраты - если они себя могут окупают или могут потенциально купить, тогда поддержка локализаций имеет смысл, если нет - то нет.
Да и в целом поддержка этого и надежда, что это упростит в будущем возможную локализацию даст скорее ложную иллюзию, что это можно сделать просто и быстро. Более того, даже проект который уже имеет локализацию на разные языки может оказаться не готов к другому языку, потому что у него текст справа на лево или сверху вниз, а не слева на право. Или более простое - высота символов, чтобы текст было комфортно читать, выше.
Более того к моменту когда проекту понадобится локализация или он будет выложен в опенсорс, могут пройти годы и за это время он будет не единожды переписан. И время которое якобы съэкономилось на подключение нового языка, если такое сучилось, с лихвой было перекрыто лишними затратами на гипотетическую поддержку.
Сомнительное заявление. Проще для кого опять же? Я говорю о подходе в принципе. Надо смотреть на мир чуть шире.
Для того, кому этот язык родной. В жизни не поверю, что французу или вьетнамцу удобнее читать на английском языке в противовес их родному. Причем тут смотреть на мир шире?
А в какой момент у нового проекта наступает нужность добавления других языков?
Зависит от проекта, может и никогда не наступить.
Кто вообще может узнать и заинтересоваться вашей библиотекой или фреймворком зарубежом, если никто просто не может понять что это?
Это уже не просто что-то написаное по заказу российской компании. Если просто что-то выложить на условный гитхаб, то об этом сам по себе мало кто узнает. Нужно продвигать. Язык(и) используемые для документации будут зависеть от "рынков" продвижения. Для увеличения охвата, в опенсорс проекте, имеет смысл и комментарии писать на английском и переменные называть на нем же, просто тогда охват будет больше.
К тому же продвигать продукт на разные рынки и сделать код и внутреннюю документацию открытыми - это разные вещи. Если код проекта и внутренняя документация закрыты, то всё равно на каком языке там комментарии. Главное, чтобы с пользователем продукт "разговаривал" на нужном языке.
Так что если есть заказчик - то он решает нужна локализация, на каком языке будет вестись разработка, и да вполне может быть, что требование германского заказчика будет то, что вся документация и комментарии к коду должны быть на немецком и плевать откуда команда разработки и на каком языке она говорит. Аналогично и для российской компании.
Ну и опять же, возвращаясь к началу статьи, про программу, которая "написанная по заказу российской компании и для российского пользователя". Если такая программа попала в руки зарубежного пользователя, то он, наверно, понимает, что это и зачем, а если нет, то скорей всего оно ему и не надо.
С некоторой вероятностью, ему может быть полезно что-то выложенное в опенсорс, но тут автор решает, что и как ему удобно. Хочет на русском, хочет на арабском или китайском пишет. Он мог это выложить просто чтобы где-то еще держать свой код, ему так разрабатывать удобнее. Пользователи которые наткнулись на этот проект и которым он помог решить их задачу, могут потратить свое время и предложить локализацию или перевод документации в рамках пул-реквестов.
В жизни не поверю, что французу или вьетнамцу удобнее читать на английском языке в противовес их родному. Причем тут смотреть на мир шире?
Уж поверьте. Мне, при родном русском, на порядок проще любой технический текст и читать, и писать по-английски. Хотя бы уже из-за недостатка терминологической гибкости в русском, где и undefined behavior (нет определения поведения), и undetermined behavior (не определён выбор поведения), оба оказываются "неопределённым поведением".
Можно одинаково перевести, а можно и по-разному: undefined behavior - неопределенное, undetermined behavior - неоднозначное (недоопределённое, неустановленное, неопределяемое) поведение. Но во втором случае скорее поймут, если использовать недетерминированное поведение.
Ну и если тот кто будет читать, то что вы написали плохо знает английский, на уровне школы, то он просто в гугл-транслейте переведет, ваш текст и так же получит в обоих случаях "неопределенное поведение". Так что писать надо так, чтобы было удобно и понятно целевой аудитории. А если пишете только для себя - то пишите так как вам удобно.
Ну и если тот кто будет читать, то что вы написали плохо знает английский, на уровне школы, то он просто в гугл-транслейте переведет, ваш текст и так же получит в обоих случаях "неопределенное поведение". Так что писать надо так, чтобы было удобно и понятно целевой аудитории.
Тут вы совершенно правы, писать надо для целевой аудитории. И я сильно сомневаюсь, что люди "плохо знающие английский" входят в целевую аудиторию технических текстов. Так же как люди не знающие латынь явно не входили в целевую аудиторию европейских учёных XII века, а люди не знающие древнегреческого -- в целевую аудиторию римских учёных классического периода.
Запросто, особенно учитывая круг компаний, которые автор упоминает - российские компании, для российского пользователя. Причем уровень владения английским будет разным и я не про "писать", а про "читать". Кому-то, как и автору, проще читать и писать на английском, кому-то писать и читать будет легче по-русски. Если уровень всех потенциальных потребителей достаточен для беглого чтения, то да можно и писать, по договоренности. Но это не является какой-то догмой, как считает автор. Ради чего намеренно усложнять и без того сложную вещь как коммуникация? А документация и комментарии к коду - это тоже, своего рода, вид коммуникации между людьми.
В международных компаниях, или тех, что планируют нанимать разработчиков из разных стран, там да, вопрос на каком языке писать документацию и комментарии стоит иначе. Но в полностью местной компании, работающей на местный рынок писать документация на иностранном языке из предположения, что все остальные должны знать этот иностранный язык - странно.
Опять же, документацию и код могут читать не только разработчики и тестировщики, да и в целом начинающие специалисты могут хуже владеть иностранным языком, меньше сталкиваться с литературой на нем, просто потому, что достаточно хороших переводов. Если очень хочется практиковаться в английском, можно внутри компании организовать разговорные клубы.
Ну и в целом, касательно языка - почему тогда существует ресурс habr? Если все технические специалисты предпочитают писать на английском, а в русском недостаточно гибкости и терминов. Точнее, почему тут появляются технические статьи на русском и переводы с английского, и переводы воспринимаются в целом хорошо? Причем и сам автор тут же пишет свои статьи по-русски. Что на мой взгляд, как раз и подтверждает востребованность и документации, и комментариев на русском языке в русскоязычных компаниях.
Если в компании есть не русскоговорящие, то тогда да, стоит использовать другой язык. Но снова, если русскоговорящая команда хорошо знает, например, испанский и английский, а другая часть команды лучше говорит на испанском, чем английском, то лучше для документации выбрать испанский язык.
Вы вывели свою трактовку того что написано, а затем пытаетесь её же опровергнуть. Ни кто говорит о том, что надо общаться на иностранном языке. Тезис очень простой - раз вы уже пишите код на языке основанном на английском, то почему бы и его технические атрибуты не писать на английском. И если это делать, то такой продукт будет легко адаптировать сразу на любой другой язык.
Более того, я специально оговорился, что если команда договорилась этого не делать по каким-то причинам - ради бога. Русский так русский как базовый. Опять же это никак не мешает сделать программу локализуемой изначально.
Обоснованным должно быть решение именно сделать программу для конкретного языка и под конкретную страну. А не наоборот.
Обоснованным должно быть решение именно сделать программу для конкретного языка и под конкретную страну. А не наоборот.
Я как раз вот с этим и не согласен. Если нет потребности в данный момент в поддержке локализации, то и не надо её тащить. Появится - тогда и надо добавлять. Потому, что затраты на сопровождения большие и к моменту необходимости локализации проект может быть переписан и не один раз.
И на мой взгляд, есть еще некотор противоречие в том, что для пользователя вы хотите, чтобы был его родной язык, причем не только для пользователя, но и для специалистов технической поддержки продукта с его стороны (внешние по отношению к компании), когда говорите о журнале. Но для самих себя предлагаете писать разработчикам на иностранном языке.
Ну и во внутреннюю документацию так же заглядывают специалисты технической поддержки, чтобы лучше понимать как работает система и чем может быть вызвана та или иная ошибка. Специалисты первой линии, когда к ним приходят с вопросам пользователи. В крупных компаниях, до разработчика коммуникация с пользователем может и не дойти никогда.
| Гуглить слова тоже надо правильно - в контексте предложений, а не буквально
context.reverso.net , не благодарите)
Begin /* Локализация