27.09.2012 18:26, Sergey V Turchin пишет: > On 27 сентября 2012 14:07:44 Pavel Mihaduk wrote: >> http://en.wikipedia.org/wiki/Commit вообще залинкована на русскоязычную >> статью о http://ru.wikipedia.org/wiki/Commit_(SQL), и что с того? > Вот и используйте только англоязычный вариант. > Этот вариант желающие используют уже сейчас, переключая LC_MESSAGES. Собственно говоря, это не самый плохой вариант, учитывая возникшие альтернативы ("отправить подготовленное состояние рабочего дерева в хранилище исходных кодов"). И всё бы ничего, но есть у такого подхода недостаток, непокрываемая область.
На большинстве кнопочек и прочих менюшек надписи вообще можно заменить пиктограммами, и результат не сильно хуже будет. Этого не сделано до сих пор просто по причине трудоёмкости рисования визуально отличающихся друг от друга пиктограмм, и потому, что пиктограмма сложнее описывается через речь, меньше возможностей для дистанционного обучения. Человек в данном случае ориентируется не на глубинный смысл термина, его литературность и бла-бла, а на связь в его (натренированном) мозгу между некоторой меткой и сутью выполняемых действий. "Профессиональный пользователь" в данном случае отличается от "непрофессионала" ровно тем, что в мозгу профессионала хранится больше связей между метками и действиями, причём, связи эти переиспользуются при переходе из одной программы в другую. Естественно, чем метка короче, более узнаваема и стандартизована, тем проще к ней привыкнуть. На таком уровне "речь", "язык" попросту не нужны, такие сигнальные системы доступны даже низшим обезьянам и хомячкам (кроме шуток, есть исследования и книжки по данной теме). А вот с всплывающими подсказками, статьями помощи и прочими элементами интерфейса, в которых используется связный и, местами, нетривиальный текст, ситуация много хуже. Там нужен перевод, причём, перевод аккуратно и точно доносящий смысл сказанного автором программы/техписом. Я натыкался в .po-файлах (того же KDevelop и других программ) на сообщения, где использовались настолько нетривиальные конструкции, что в них не получалось разобраться даже переводившему их человеку (чаще всего, какой-нибудь страдательный залог в сложноподчинённых предложениях итп). В результате, в переводе субъектность и объектность менялись местами, и исходный смысл полностью переиначивался. Естественно, в таких случаях текст на родном языке воспринимается гораздо проще и безошибочнее, чем текст на любом неродном. Исключение составляют, наверное, лишь полные билингвы, но таковые встречаются крайне редко даже в смешанных семьях. Поэтому перевод таких сообщений и, шире, текстов нужен даже тем, кто, в целом, не жалуется на незнание английского. У таких развёрнутых сообщений должна быть общая с интерфейсом терминологическая база. Просто для того, чтобы не приходилось разжёвывать, какие кнопочки или пункты меню упоминаются в этих сообщениях. Интерфейс, как уже сказано выше, накладывает на терминологию ограничения на размер сверху, узнаваемость, если угодно, иконографичность. Вот, пожалуй, и все. Если кому-то удастся придумать терминологию, которая будет удовлетворять указанным ограничениям и при этом будет базироваться на русских/восточнославянских корнях - ну, замечательно, будем использовать её, причём, совершенно добровольно и с радостью. Пока же, к сожалению, ничего подобного не просматривается. В то время как английская терминология - вот она, в "шаговой доступности" и вполне удовлетворяет указанным ограничениям. Такие дела. АМ _______________________________________________ kde-russian mailing list kde-russian@lists.kde.ru https://lists.kde.ru/mailman/listinfo/kde-russian