«Старое железо», «Гаджеты», «Планшеты», «Ноутбуки», «Игры и игровые консоли»
в теги «железо» и «игры и геймдев»? Кажется текущее деление слишком избыточно и неоднозначно.
P.S. Простому работяге хотелось бы читать про хард штуки отдельно от остальных трендов по типу «выгорание» и «собеседования», которые нагоняют лишь тоску
Общепринятой практикой является написание фразы на одном из языков (русский/английский) и перевод на нужный, то бишь с токенизацией у вас будет: "У {{user_name}} было {{count_apple}} {{apple}}, {{count_pear}} {{pear}}, из которых {{count_with_worm}} червивые", для английского аналогично "{{user_name}} had {{count_apple}} {{apple}}, {{count_pear}} {{pear}}, {{count_with_worm}} of which were wormy"
Хотите сказать, что с i18next у вас будет по-другому? В чем вообще претензия? Склонение существительных (и их окончания) на различных языках явно не задача i18next и подобных библиотек.
Здесь вопрос весь заключается в том, что пользователи habr или сторонние люди пришедшие из поисковика будут искать? Интернализация или локализация? Все же локализация более распространенный термин.
Скорее не в чем смысл, а как себе это вообще можно представить? Допустим, есть микросервис переводов, который динамически отдает нужные, на этапе компиляции приложения мы можем сгенерировать типы typescript, но в runtime мы не получим никакой пользы. Да и к тому же, если, например, значение ключа изменится, то что вы предлагаете делать?
Приведите пример, который невозможно решить с помощью i18nano. Все что вы пока написали не является аргументом, плюрализация решается спокойно через переменные как было расписано в статье.
Вы можете реализовать функцию, которая по переданному параметру будет отдавать нужный индекс. Не поймите меня превратно, но поддержка для всевозможных языков слишком громозкая, да и покрыть все кейсы задача почти невозможная, даже из вашего примера few, many и other не являются в чистом виде числительными, то бишь требуют дополнительной логики, которую просто не решить с помощью key-value переводов.
Вынужден не согласиться, API Gateway скорее про другое. Если вы внимательно прочитаете шапку статьи, то для решения поставленной задачи обычно поднимают целый сервер, который в той или иной мере располагается под reverse proxy.
Это не всегда решение, например, если нужно взаимодействовать со сторонним API. Что в таком случае делать изволите? Скажем, если есть поддержка JSONP это одно, а если нет?
По поводу кредов и кук, можно поддержать, использовав proxy_cookie_domain, но вообще это отдельная тема, как их правильно преобразовывать и обрабатывать.
Звучит конечно хорошо, но в реализация страдает. На hackerone описал кучу уязвимостей со стороны vk-bridge, которые, к слову, воспроизводятся на всех платформах, добавил ссылку на миниапп, где они все воспроизводятся просто по нажатию на соответствующую кнопку, и просто отклонили. То ли не смогли нажать, то ли побоялись.
Если говорить про кастомные реализации, то у nodejs тоже есть переписанный вариант fetch (https://github.com/nodejs/undici), который к слову быстрее node-fetch реализованного поверх встроенного http клиента.
? blazing fast ? memory safe ?
Ничего так не дискредитирует rust, как люди, которые о нем пишут
Интересно больше то, что на сами Goophone тоже есть подделки, точнее копии ещё хуже качества, которые выдают себя за Goophone
Почему бы не перегруппировать
в теги «железо» и «игры и геймдев»? Кажется текущее деление слишком избыточно и неоднозначно.
P.S. Простому работяге хотелось бы читать про хард штуки отдельно от остальных трендов по типу «выгорание» и «собеседования», которые нагоняют лишь тоску
Но не про качество
/thread
Такое ощущение, что статью писала нейросеть по типу ruGPT-3
Есть ещё нативные варианты, например, https://github.com/rsms/markdown-wasm
Если речь идёт о скорости, то почему их не рассматривать...
Что же вы свой же пример упростили, да и ещё добавили уйму дополнительных ключей с магическими постфиксами.
Реализация дополнительных функций для обработки числительных спокойно решается теми же плагинами, которые, к слову, появились у i18next не сразу.
Общепринятой практикой является написание фразы на одном из языков (русский/английский) и перевод на нужный, то бишь с токенизацией у вас будет: "У {{user_name}} было {{count_apple}} {{apple}}, {{count_pear}} {{pear}}, из которых {{count_with_worm}} червивые", для английского аналогично "{{user_name}} had {{count_apple}} {{apple}}, {{count_pear}} {{pear}}, {{count_with_worm}} of which were wormy"
Хотите сказать, что с i18next у вас будет по-другому? В чем вообще претензия? Склонение существительных (и их окончания) на различных языках явно не задача i18next и подобных библиотек.
Здесь вопрос весь заключается в том, что пользователи habr или сторонние люди пришедшие из поисковика будут искать? Интернализация или локализация? Все же локализация более распространенный термин.
Скорее не в чем смысл, а как себе это вообще можно представить? Допустим, есть микросервис переводов, который динамически отдает нужные, на этапе компиляции приложения мы можем сгенерировать типы typescript, но в runtime мы не получим никакой пользы. Да и к тому же, если, например, значение ключа изменится, то что вы предлагаете делать?
Приведите пример, который невозможно решить с помощью i18nano. Все что вы пока написали не является аргументом, плюрализация решается спокойно через переменные как было расписано в статье.
Вы можете реализовать функцию, которая по переданному параметру будет отдавать нужный индекс. Не поймите меня превратно, но поддержка для всевозможных языков слишком громозкая, да и покрыть все кейсы задача почти невозможная, даже из вашего примера few, many и other не являются в чистом виде числительными, то бишь требуют дополнительной логики, которую просто не решить с помощью key-value переводов.
"Вы просто поверьте - там все замечательно!" (с)
Вынужден не согласиться, API Gateway скорее про другое. Если вы внимательно прочитаете шапку статьи, то для решения поставленной задачи обычно поднимают целый сервер, который в той или иной мере располагается под reverse proxy.
Так ничего не мешает ограничить хосты в той же map ¯\_(ツ)_/¯
Это не всегда решение, например, если нужно взаимодействовать со сторонним API. Что в таком случае делать изволите? Скажем, если есть поддержка JSONP это одно, а если нет?
По поводу кредов и кук, можно поддержать, использовав proxy_cookie_domain, но вообще это отдельная тема, как их правильно преобразовывать и обрабатывать.
Звучит конечно хорошо, но в реализация страдает. На hackerone описал кучу уязвимостей со стороны vk-bridge, которые, к слову, воспроизводятся на всех платформах, добавил ссылку на миниапп, где они все воспроизводятся просто по нажатию на соответствующую кнопку, и просто отклонили. То ли не смогли нажать, то ли побоялись.
Если говорить про кастомные реализации, то у nodejs тоже есть переписанный вариант fetch (https://github.com/nodejs/undici), который к слову быстрее node-fetch реализованного поверх встроенного http клиента.