Я про них и писал :), но не всегда можно получить нулевую ставку.
Кроме того бесплатный 100% match как правило означает что на контекст переводчик тупо забивает, что и было изначальной проблемой.
Не понимаю, откуда взялось «принудительно заставлять обновлять»?
1 Я писал про fuzzy, которым можно «закрыть» изменения старым переводом
2 Потом этот fuzzy всё равно переводчики будут смотреть, и возможно даже что-то переведут
3 Скрывать любые пусть даже мелкие правки от переводчиков нет смысла
На практике конфликты достаточно редки и повторное использование вполне оправдано, при генерации в .po файле можно перечислить все файлы с указанием строк, где msgid использовался и это помогает определить — допустимо ли повторное использование или нужно разделить по контексту.
Автоматически раздавая всем вхождениям уникальный контекст получаем 100500 «OK» и «Cancel» на перевод и перевод каждого нового «OK» оплачивается отдельно :)
Вопрос ответственности.
Могут как заменить, так и не заменить — это вполне в компетенции переводчиков. Я категорически против того, чтобы эту ответственность забирать у переводчиков — менять текст и решать, что переводчикам об этом знать не обязательно(ведь русский перевод же не изменится).
Фактически разработчик меняя текст берёт на себя ответственность за использование старых переводов, а в его ли это компетенции?
Это лучше чем было, перенос части языкозависимой логики формирования текстов на сторону переводчиков требует или полноценной поддержки инструментами для перевода (CAT вроде Trados или MemoQ) или знаний со стороны переводчика.
Увы, ICU MessageFormat не удалось этого добиться за более чем десяток лет своего существования, но может Fluent повезёт больше…
Что это «последствия классического подхода gettext» на мой взгляд неудачная формулировка (gettext имеет стандартное решение этой проблемы), так как и в Fluent это точно так-же решается передачей различного контекста (id или параметра). Да, если его уже передавали — то в Fluent это решится лишь переводом, а если нет — последствия аналогичны.
Увы, тот факт что русский перевод не меняется — совершенно не означает что переводы на другие языки тоже меняться не будут — особенно в случае новомодной замены his на them. Точно так же никто не гарантирует того, что опечатка никак не повлияла на переводы.
gettext хорошо решает задачу сбора строк в перевод по исходному коду проекта, изменение, добавление, удаление. Fluent же вообще к этим задачам не относится, поэтому их нельзя сравнивать целиком.
Как формат Fluent гораздо мощнее .po
P.S. В .po даже есть msgid_plural, но его не называли «Концепцией асимметричной локализации — ключевой инновацией»
В gettext есть msgctx, в чём проблема то была?
Доработки со стороны программистов всё равно останутся, передавать переводчикам контекст всё равно придётся, число, пол и т.д.
По-хорошему переводить её заново всё равно придётся, просто старый перевод может висеть довольно долго (и не всегда это правильно). Мелкие правки неплохо закрывает fuzzy, ну и можно держать английские тексты как перевод (en.po) и править мелочи там, не трогая код.
Адаптация bitset как части стандартной библиотеки к конкретному железу — вещь полезная, но вот пример с клавиатурой на мой взгляд выбран неудачно.
Из-за этого на опрос сложно ответить объективно, например я считаю:
А. Конкретно для клавиатуры особо быстрый bitset не особо нужен, и оптимизировать его излишне, ну не зажимают часто быстро большое количество кнопок (преждевременная оптимизация);
Б. Для других задач оптимизация bitset может быть необходима;
Как-то нераскрыта обратная связь, ведь имплант в теории можно использовать не только для чтения «ввода» (мозг-компьютер), но и для «вывода» (компьютер-мозг), и это совершенно новые возможности, на порядок круче, чем текущий VR или игры вообще. :)
Майнили не только биткоин. Не думаю что гуглу нужно покупать железо, прогоревшие майнеры сами потащат железо гуглу за процент от аренды/подписки с игрушек. Ведь именно площадка — сервис привлекает пользователей. При виртуализации железо легко сменить, гугл практически ничем не рискует. Игрушки всё-таки венчурный бизнес, вот пусть майнеры и рискуют окупаемостью железа :).
Конечно все хотят продать по-дороже и цена на видеокарты не спешит падать.
Если не можешь продать железо, то будешь хотя-бы сдавать его в аренду. А как иначе окупить?
Стоимость железа постоянно падает, нужно как-то держать волну спроса и куда-то его девать/обновлять. Вот недавно была волна с майнерами биткоинов, после них, думаю, осталась масса неплохого железа. Его надо куда-то девать, ведь уже нового наделали :)
Среднестатистические 20 баксов. И эти 20 баксов считались исходя из предполагаемых объёмов продаж. Поскольку сейчас они лишь портируют уже существующие игры на эту платформу, то основную часть затрат они уже отбили за счёт старых-добрых продаж. А учитывая, что число потенциальных пользователей браузера на порядок больше, то и цену можно сделать на порядок меньше. Проблем с мощностями нет, можно сказать что они даже простаивают если Google решил пустить их на игрушки :)
Как правило рассчитываются исходя из необходимой точности для приятного внешнего вида, косвенно привязаны к количеству пикселей/уровню детализации. Нет смысла генерировать карту теней 4096х4096 если окошко 640х480. В зависимости от реализации, например если оба игрока находятся в одной комнате — карту теней можно повторно использовать без вычисления.
GI
Не совсем понимаю связь с Global Illumination — она довольно сложно считается сама по себе, игры обычно используют заранее вычисленные значения/текстуры. Самих текстур может потребоваться больше — да, но текстуры скорее всего будут повторно использоваться. Кроме того для меньшего окна можно использовать и текстуру по-меньше. Всякие пост-процессинг фильтры обычно завязаны непосредсвенно на пискелях.
Симуляции
Как и GI — вы правы что они не зависят от количества пикселей, но и от количества игроков они тоже не явно зависят. Одиин игрок вполне может создать больше хаоса своими действиями, там что-нибудь большое взорвать, чем несколько других игроков вместе взятых. Да, в теории они все будут творить по-максимуму, но это скорее исключение. Накладные расходы сетевой игры на симуляцию даже больше чем в split screen, но игры делаются.
Затраты на обработку геометрии
Использование уровней детализации геометрии решает эту проблему
особенно о консолях
Как ни странно split screen намного более распространён на консолях, чем на ПК
Вот допустим в самом худшем случае добавление второго игрока будет требовать в два раза больше ресурсов, но не больше же.
Если игра уже прекрасно идёт с родной частотой работы монитора — значит ресурсов ей достаточно. И добавление второго игрока, пусть даже с просадкой FPS в два раза (а из-за запаса это будет меньше чем в 2 раза) вполне допустимо. Т.е. для меня как игрока это не проблема, я согласен — дайте мне эту возможность!
Сейчас один играет 120 FPS, а вдвоём упадёт до 60ти.
Это правда существенно, даже в наихудшем случае? Я так не считаю
Кроме того бесплатный 100% match как правило означает что на контекст переводчик тупо забивает, что и было изначальной проблемой.
1 Я писал про fuzzy, которым можно «закрыть» изменения старым переводом
2 Потом этот fuzzy всё равно переводчики будут смотреть, и возможно даже что-то переведут
3 Скрывать любые пусть даже мелкие правки от переводчиков нет смысла
Автоматически раздавая всем вхождениям уникальный контекст получаем 100500 «OK» и «Cancel» на перевод и перевод каждого нового «OK» оплачивается отдельно :)
Могут как заменить, так и не заменить — это вполне в компетенции переводчиков. Я категорически против того, чтобы эту ответственность забирать у переводчиков — менять текст и решать, что переводчикам об этом знать не обязательно(ведь русский перевод же не изменится).
Фактически разработчик меняя текст берёт на себя ответственность за использование старых переводов, а в его ли это компетенции?
Увы, ICU MessageFormat не удалось этого добиться за более чем десяток лет своего существования, но может Fluent повезёт больше…
Как формат Fluent гораздо мощнее .po
P.S. В .po даже есть msgid_plural, но его не называли «Концепцией асимметричной локализации — ключевой инновацией»
Доработки со стороны программистов всё равно останутся, передавать переводчикам контекст всё равно придётся, число, пол и т.д.
Из-за этого на опрос сложно ответить объективно, например я считаю:
А. Конкретно для клавиатуры особо быстрый bitset не особо нужен, и оптимизировать его излишне, ну не зажимают часто быстро большое количество кнопок (преждевременная оптимизация);
Б. Для других задач оптимизация bitset может быть необходима;
Конечно все хотят продать по-дороже и цена на видеокарты не спешит падать.
Если не можешь продать железо, то будешь хотя-бы сдавать его в аренду. А как иначе окупить?
Среднестатистические 20 баксов. И эти 20 баксов считались исходя из предполагаемых объёмов продаж. Поскольку сейчас они лишь портируют уже существующие игры на эту платформу, то основную часть затрат они уже отбили за счёт старых-добрых продаж. А учитывая, что число потенциальных пользователей браузера на порядок больше, то и цену можно сделать на порядок меньше. Проблем с мощностями нет, можно сказать что они даже простаивают если Google решил пустить их на игрушки :)
Ну что-же, давайте по порядку:
Как правило рассчитываются исходя из необходимой точности для приятного внешнего вида, косвенно привязаны к количеству пикселей/уровню детализации. Нет смысла генерировать карту теней 4096х4096 если окошко 640х480. В зависимости от реализации, например если оба игрока находятся в одной комнате — карту теней можно повторно использовать без вычисления.
Не совсем понимаю связь с Global Illumination — она довольно сложно считается сама по себе, игры обычно используют заранее вычисленные значения/текстуры. Самих текстур может потребоваться больше — да, но текстуры скорее всего будут повторно использоваться. Кроме того для меньшего окна можно использовать и текстуру по-меньше. Всякие пост-процессинг фильтры обычно завязаны непосредсвенно на пискелях.
Как и GI — вы правы что они не зависят от количества пикселей, но и от количества игроков они тоже не явно зависят. Одиин игрок вполне может создать больше хаоса своими действиями, там что-нибудь большое взорвать, чем несколько других игроков вместе взятых. Да, в теории они все будут творить по-максимуму, но это скорее исключение. Накладные расходы сетевой игры на симуляцию даже больше чем в split screen, но игры делаются.
Использование уровней детализации геометрии решает эту проблему
Как ни странно split screen намного более распространён на консолях, чем на ПК
Вот допустим в самом худшем случае добавление второго игрока будет требовать в два раза больше ресурсов, но не больше же.
Если игра уже прекрасно идёт с родной частотой работы монитора — значит ресурсов ей достаточно. И добавление второго игрока, пусть даже с просадкой FPS в два раза (а из-за запаса это будет меньше чем в 2 раза) вполне допустимо. Т.е. для меня как игрока это не проблема, я согласен — дайте мне эту возможность!
Сейчас один играет 120 FPS, а вдвоём упадёт до 60ти.
Это правда существенно, даже в наихудшем случае? Я так не считаю