Комментарии 19
Прошу совета людей, профессионально занимающихся переводом
Как грамотней (и доступней для понимания) переводить слово "feature", которое используется в контексте "дополнительной опции/возможности программы"? Слово "фича" хотя и резко понятное, однако при его использовании текут слёзы. А слово "функция" очень сильно ассоциируется с "function" и тем самым сильно искажает смысл предложения.
Иногда подопытный материал может содержать очень странную композицию. Например, в оригинальном тексте данной статьи много предложений не объединены в абзацы. Я рассматриваю понятие "абзац" как группировку однородных единиц изложения и в данном случае испытываю сильное желания в объединении предложений. Я что-то нарушаю, если сгруппирую предложения?
Исходя из предыдущего вопроса, насколько сильно можно модифицировать материал в целом? Часто я вижу, что некоторые аспекты можно видоизменить для более легкого восприятия материала: что-то убрать, где-то приписать, но при всём этом сохраняя общую структуру мысли. Однако, я обязательно буду сохранять логику и стиль автора и не посягать на что либо. Где грань модификаций?
Часто, материалы поставляются с очень сильной (и обильной) рекламой всего и вся. Я считаю, что сохранять данную информацию обязательно. При этом, если рекламных материалов слишком много (хотя информация всё равно качественная) или же они не соответствуют моральным (и прочим) личным ориентирам, то я просто не буду переводить такой материал. Как поступаете вы?
Какие права можно нарушить, переводя материалы из открытых источников (например, medium)? Обязательно ли получать личное разрешение автора на перевод?
В подобном случае хорошо смотреть для какой аудитории вы пишете. Мне кажется на хабре можно смело использовать слово "фича". Заимствования - важная часть эволюции любого языка, и грустить здесь не о чем :) Но если вам нужен более классический и сдержанный вариант, есть еще слово "функционал".
Это неоднозначный вопрос. На мой взгляд, в данном случае за такой структурой вряд ли стоит сознательный замысел автора, скорее это небрежность. Поэтому добавление абзацев я бы рассматривал как правку - сродни исправлению опечатки в исходном тексте. Если бы в тексте были целенаправленно сделанные абзацы, менять их на структуру которая вам кажется более интересной уже было бы "самодеятельностью".
Когда вы делаете перевод, вы можете дополнить его корректорской работой - поправить случайную опечатку или помарку, и это останется переводом. Когда вы меняете логическую структуру текста или добавляете информацию от себя, получается, что вы вводите читателя в заблуждение - в шапке же написано "перевод статьи такого-то", а в тексте ваши собственные мысли. Но есть хорошее и простое решение - комментарии переводчика, которые можно вставлять хоть прямо в текст, при условии, что они четко обозначены и не затрудняют чтение. Или же вы можете написать уже собственную статью со ссылками и цитированием оригинального текста, где раскрываете тему по-своему, или даже вступаете в полемику с автором оригинала.
Тут полностью с вами согласен.
Если не указано иного, то все права на статью на Medium за автором статьи (сурс). На других платформах смотрите информацию о лицензии. Чтобы у вас появилось право переводить (т.е. модифицировать) контент и распространять его копии, такое право должно быть вам предоставлено автором. Вы можете написать собственную статью с цитированием оригинала, для этого разрешения не нужно. Перевод самостоятельным произведением не считается, а критический разбор или отзыв считается. Грань тонкая и субъективная:
it is permissible to use limited portions of a work including quotes, for purposes such as commentary, criticism, news reporting, and scholarly reports
(сурс)
Насколько я помню, на медиуме есть возможность написать автору в личку. Большинство авторов будут рады дать разрешение на перевод, потому что во-первых внимание к твоей работе это безумно приятно, а во-вторых создает покрытие аудиторий, которые иначе были бы недосягаемы, при этом без усилий со стороны автора.
У вас получился очень хороший перевод, особенно хочется отметить что отлично соблюден баланс между избыточным использованием англицизмов и компульсивной руссификацией всего подряд.
Спасибо за развёрнутый комментарий! Все ответы крайне полезны для меня. Слово "функционал" - это то, что я искал :)
Минутка занудства. Функционал – это функция, заданная на произвольном множестве и имеющая числовую область значений. С точки зрения грамотности, уж лучше "фича" – поскольку буквальный перевод не передает нужны смысла, калька (тем более, такая устоявшаяся, тем более, в статье, рассчитанной на программистов) лучше, чем неправильное слово.
Есть еще слово "возможность". Реализовать ту или иную фичу/возможность/функциональную возможность
Умные люди сделали для флаттера шикарную архитектуру - есть стейт, есть экран с виджетами на экране. Меняешь стейт - меняются виджеты. Упрощает юайный код в нулину, удобно и убирает кучу гемороя.
Но не, это слишком просто, хочу лепить блок через блок, класс через класс, обложить парсинг джейсонов, он простите, бизнес-логику тестами и другой сектантской мутью.
Че, если не усложнять код, то станет понятно что вы просто кнопки красите? Мальчик с кучей "умных" слов в тексте, кто ты без них?
А вы что-нибудь писали больше, чем Hello World или стандартный Counter?
Да, я работал на приложениях без этой переусложненной архитектуры, и все нормально со стабильностью и сопровождаемостью кода. Для большинства приложений такой оверинженеринг не нужен. Обычно приложения тонкие клиенты. Для глобального стейт менеджмента (в основном это данные профиля пользователя) использовал InheritedWidget, стейт нет уж и часто меняются, чтобы вызвать серьезные проблемы с производительностью. Если даже и возникнут в некоторых местах, есть и другие механизмы стейт менеджмента, там уже можно отдельно оптимизировать эти "бутылочные горлышки". Но в целом не очень много глобального стейта, большинство инкапсулировано в компонентах, и как раз так легче отлаживать и понять, что пошло не так.
Может быть для некоторых приложений такая сложная архитектура оправдана, но я лично на работе не видел такого проекта. Для многих проектов это больше вреда чем пользы, так как существенно замедляет разработку и повышает порог вхождения. Для всего есть баланс, крайности только вредят.
Те же самые мысли. На работе мне как раз достался такой проект. И даже при небольших изменениях такое впечатление, что больше борешься с архитектурой и хочешь обойти ее. Коллега же только хвалит, типо оно круто, scalable, testable, UI изолированно от "логики" итд. Говорит в каком-то проекте один очень крутой профессиональный флаттер разраб использует его поэтому и мы решили на него перейти. Ну тогда может и Ангуляр приложения писать в таком стиле ради того, чтобы "UI было изолированно от логики"?! Для ~95% приложений вряд ли такая сложность оправдана, она только существенно замедляет разработку и поднимает порог вхождения.
Не знаю, даже думаю уволиться с этой компании.
Зачем всё это если есть GetX?
Все эти остальные паттерны ничего кроме тонны кода ради кода не привносят.
GetX кусок говна
https://www.youtube.com/watch?v=pBgXCdC0Cxw
Послушал. Там аргументов ноль. На reddit тоже почитал треды. Ни единого аргумента нет кроме слепой веры в то что код ради кода и классы ради классов это хорошо.
Создается впечатление что разрабы Flutter его криво задизайнили, а создатель GetX пошел им наперекор и исправил кучу врожденных уродств и за это его тупо начили хейтить.
Зачем писать два класса там где можно написать один? Зачем писать код там где его можно не писать?
В смысле не единого аргумента? вам же на стриме весь этот getx разобрали включая вранье про стримы которые быстрее стримов самого дарта, можешь еще твит Филипа Грачека почитать он тоже высказывался об этом божественном пакете, хотя что для гетиксера мнение одного из ведущих разработчиков флаттера, что он может об этом знать
Bloc это распиаренный патерн, вот и все. Если Вы сами делаете проект то все нормально. У этого паттерна четко прослеживается зависимость со сложностью, когда блок вешается на блок и блоком погоняет. Это ад в больших приложениях.И потом читать UI в котором тонны вызовов провайдеров это как раз "не независимый UI" тут я поддерживаю GetX. В нем легко делается соответствие дизайн-документа и логики страниц.А вот в блоке тут проблема ибо всегда можно выделить обьекты не в той иерархии в которой составлен дизайн.Для тех кому надоел Bloc откройте для себя GetX а далее можно и на Nylo перепрыгнуть
Nylo - впервые слышу о таком. Что за зверь?
https://nylo.dev/. это микрофреймворк для флаттера. Есть все что нужно и очень элегантно сделан.Кстати если будете с нуля что то делать начните с него - не пожалеете.Постучите мне в личку я помогу
Автору статьи большое спасибо, хорошо подал материал, умно продуманная архитектура. Многие комментаторы думают что bloc это код ради кода. В маленьком проекте bloc - это код ради кода, там getx нормально подойдёт, а bloc лишь увеличит порог вхождения. В большом проекте bloc, в форме mvc и чистая архитектура - незаменимое то, порог входа уменьшится значительно, а getx превратится в кучу говна.
Проектируем flutter-приложение «чистым» способом используя bloc