Planet — это класс, а Earth — это конкретный объект, одна из планет :)
Старался сделать все максимально рационально.
Объект Planet всегда один и тот же, и это всегда Земля:
/**
* @return string
*/
public function getShortName()
{
return 'Earth';
}
/**
* @return string
*/
public function getLongName()
{
return 'The Blue Marble';
}
Вообще, все нормально будет — скажем, до 1991-ого года пользователь имел «родился в Ленинграде», после 91-ого «родился в Санкт-Петербурге» (что абсолютно верно). Ничего не меняя в базе или коде.
Пропадать города будут очень, очень редко. Не уверен, как GeoNames поступают в таких случаях. Если просто удаляют из базы навсегда — то да, надо думать как такие случаи обрабатывать.
В GeoNames есть все города с населением выше 1000 людей — этого достаточно должно быть большинству приложений.
Facebook, к примеру, имея миллиарды капитала, не может до сих пор многие ошибки в географии исправить. Подозреваю, что качество данных было бы выше, если бы любой пользователь мог исправлять ошибки (а в случае пакета на GitHub так и будет)
Хорошо, согласен про зависимости. Но все еще настаиваю на том, что работать в будущем (то, что называют термином 'maintainability') будет проще с приложением, использующим известные, документированные API и конвенции. В данном случае использовать GeoNames вместо специфичных для конкретного приложения идентификаторов – это как раз переход на API, на конвенцию, которую кто-то уже написал за нас.
Лично мне было бы удобно, что во всех моих приложениях код города 15 – это город X, и при этом мне не надо самому ничего документировать.
GeoNames – это, как говорится, не идеально, но лучшее, что у нас сегодня есть.
Если приложений было 5 – вы заменили 5 зависимостей всего одной.
Если приложение было одно – вы заменили собственную кустарную (живущую в адресном пространстве конкретного приложения) зависимость – глобальной, стандартизированной, проверенной годами. Что не так уж и плохо само по себе! ;-)
Выбор – можно по ISO, а как пользователю отображать? :) А если сайт на 15 языках?
Про Австралию согласен, это так – пример. Про адреса в свободной форме, мне кажется, было бы полезным какой-то умный парсер адресов сделать, который умеет приводить адреса вроде «УЛ НИКИТИНА МОСКВА» в «ул. Никитина, Москва, 125000 Россия». Точно знаю, что некоторым проектам это нужно
Модный на сегодня ответ – абстракцией. Уменьшением зависимостей, или то что в английском называется 'decoupling'.
Если у меня имеется 5 приложений и всем нужны географические данные, мне проще на всех 5 использовать идентификаторы GeoNames, чем 1) использовать 5 разных наборов 2) придумывать свою конвенцию.
А если выбирать не из своих систем – я не смог ничего глобального найти кроме GeoNames. Если есть что-то еще – то надо будет просто добавить эту систему в пакет, разработчик сможет выбрать, чему он больше доверяет в долгосрочной перспективе :)
Ну, выбор страны как правило – все-таки выпадающий список, даже если все остальное в свободном формате вводится. Это по моему опыту онлайн-шоппинга :)
А тут в Австралии так вообще — любят принудительное распознавание адреса. Если сайт не смог распознать (интерпретировать) адрес — пользователь не может продолжить. Таким образом, можно использовать подобный пакет без проблем (точнее даже — он уменьшит количество проблем :)
Потому что есть ещё города, а для них нет никаких стандартных кодов, насколько я знаю. Штатам, скорее всего, полезно будет всё, что имеется – GeoNames, ISO 3166-2, FIPS. Таким образом будет делом разработчика – к чему привязаться.
Ещё один плюс GeoNames – идентификаторы уникальны для всей планеты. Необязательно хранить код страны рядом с кодом области.
Надежность собственных решений — это заблуждение. Все нормальные open source пакеты автоматически тестируются, показывают уровень покрытия код тестами и так далее.
Плюс всего один — гибкость, можно что-то изменить под себя, добавить. Но это как правило решается через fork или pull request.
У нас были как-то проблемы с библиотекой ZeroMQ, к примеру. Написали автору, заплатили как консультанту — он срочно исправил баг в библиотеке (который видимо больше никого не беспокоил). Даже так получилось быстрее и дешевле, чем свое решение.
У меня ощущение, что нежелание использовать чужое — берет истоки где-то в характере разработчика, это что-то эмоциональное. Тут рациональности нет вообще.
Ну, Вы прямо против всего мира решили пойти. Последние годы почти во всех популярных языках тренд — использовать пакеты (gems в Ruby, packages в PHP, cocoa pods в Xcode, components в bower/npm и так далее) для быстрой и эффективной разработки.
Есть даже термин, популярный сейчас в стартап-сфере — комбинаторная инновация. Не помню, кто первым теорию выдвинул, но суть ее в том, что сначала появляется базовая инновация, а затем на ее основе вырастает множество производных инноваций (в которых по-разному скомбинированы элементы, отсюда и название).
Примеры: электроника в 1920-ых, интегральные схемы в 1970-ых.
Сейчас происходит тоже самое. На одном GitHub находится более 2-ух миллионов репозиториев. Работа современного инноватора (за исключением действительно уникальных, новых функций) — собрать из этих готовых кусков новый продукт, сделать инновацию посредством комбинирования.
Если каждый раз сознательно изобретать велосипеды — об Agile/Lean разработке можно просто забыть. Это очень дорого и неэффективно.
Потому что предложенная модель – это CDN, это content delivery network.
Имеется оригинальный сервер с контентом, имеется сеть пограничных серверов (с функцией перевода), которые контент распространяют.
CloudFlare – это CDN, который умеет оптимизировать картинки, минимизировать JavaScript, вставлять Google Analytics. Тут предлагается CDN, который умеет парсить HTML/JavaScript и заменять в нём тексты.
Цепочка CF<->переводчик упомянута только для подчеркивания гибкости, поддержки legacy клиентов и так далее. Это не является рекомендацией, просто это работает.
Согласен, но так можно сказать про любой SaaS вообще. Плата за удобство и гибкость – как раз вынесение за рамки приложения, это как две стороны одной монеты.
Можно добавить на стороне CDN возможность выгрузки всех переводов в удобных форматах, чтобы уверить пользователя, что его не привязали. Захотел – сделал себе экспорт в текстовые файлы и ушёл.
Контроль, кстати, не полностью теряется. Предполагается, что клиент может через панель управления контролировать все переводы, оспаривать варианты, требовать повышения качества и так далее. Клиент всегда прав, CDN просто пытается сделать его жизнь проще.
А что если CDN-переводчик сам неплохо кэширует? :-) кэширующий CDN – дело тривиальное, поэтому их так много сегодня.
Пользователи, которые любят CF и лояльны к нему, остаются как: CF – translator – origin, а кто-то кто нашёл сервис отдельно и не знает про CF может просто: translator – origin
Схема translator – CF – origin просто как пример была дана, как доказательство, что по большому счету – разницы то нет откуда вернулся HTML контент, его можно перевести. Это нерационально, но это гибкость дает
Одно из рациональных решений, что приходит в голову – API получает N запросов на перевод строк, которые находятся в одном и том же месте и совпадают на процент X. Приложение понимает, что это, наверное, строка с переменной и предлагает пользователю быстро это подтвердить.
С другой стороны, этот пост-рендерный взгляд на ресурс позволяет нормально переводить тексты из БД, а не из словарей. Скажем, у нас онлайн-магазин, и мы хотим показывать "Матрёшка" как "Babushka" на английском сайте. Большинство разработчиков сейчас добавят дополнительное значение где-то в хранилище данных, таким образом далее усложняя локализацию – теперь у нас часть переводов в файлах, часть в базах.
А с точки зрения CDN – это обыкновенный текст, переводить и редактировать его можно вместе со всем остальным. Мне кажется, это достаточно удобно.
1) Если перед – нет, не ради галочки, а чтобы пользователю меньше движений делать. Представим кейс, что есть веб-сайт http://direct.site.ru, есть обёрнутый в CF https://www.site.ru. Пользователь решил добавить https://www.site.es, у него стоит выбор – выбрать как origin direct.site.ru или www.site.ru. Оба сайта (напрямую и через CF) возвращают один и тот же контент за исключением случаев, когда оригинальный сайт лежит (тут CF может показать свою красивую ошибку). Таким образом, разница сравнительно небольшая – переводить ответ от оригинального сервера или переводить ответ от edge-точки CF.
2) Смысл статьи – предложить новый метод локализации, который сейчас практически не используется вообще никем.
3) Тут Вы неправильно немного поняли концепцию, и частично виноват я сам. У каждого переведенного сайта отличаются адреса всех страниц. На выбор пользователя – это может быть домен, может быть URI.
Неважно куда приходит запрос на, скажем, site.es/index – на CloudFlare, CloudFont, CDN77 или мой собственный edge-сервер. Адрес site.es/index уникально идентифицирует конкретную страницу на конкретном языке.
Это ожидаемые вопросы и они решаемые ;-)
1) Если правильная конвенция по именам в CSS — верстка ничего ломать не будет. Если конвенции нет, то при смене дизайна или верстки достаточно в правилах адреса переписать.
2) Во-первых, это вполне себе решается в данной модели. Во-вторых, таких сценариев достаточно немного и они повторяются от сайта к сайту — вероятно, можно сделать какое-то общее решение.
3) Тоже самое, что в 2.
4) Если подобные слова используются где-то по отдельности, не как часть фразы – это может быть проблемой. Но думаю, что можно найти рациональное решение.
Вы совершенно правы, но тут проблема частично решается предлагаемым параметром 'контекст'. Если 'welcome' попалось внутри меню — пусть это будет "Приветствие", а если внутри параграфа — хочу "Добро пожаловать". Это, вероятно, не универсальное решение, но уже шаг вперед.
Перевод от API — за ним можно ставить онлайн-рынок переводчиков вроде Gengo, там качество контролируется, можно закреплять конкретных переводчиков, оспаривать тексты и так далее. Скорее всего, спустя месяц работы у большинства клиентов проблема отпадет — переводчики привыкнут к требованиям
Старался сделать все максимально рационально.
Объект Planet всегда один и тот же, и это всегда Земля:
Пропадать города будут очень, очень редко. Не уверен, как GeoNames поступают в таких случаях. Если просто удаляют из базы навсегда — то да, надо думать как такие случаи обрабатывать.
В GeoNames есть все города с населением выше 1000 людей — этого достаточно должно быть большинству приложений.
Facebook, к примеру, имея миллиарды капитала, не может до сих пор многие ошибки в географии исправить. Подозреваю, что качество данных было бы выше, если бы любой пользователь мог исправлять ошибки (а в случае пакета на GitHub так и будет)
Лично мне было бы удобно, что во всех моих приложениях код города 15 – это город X, и при этом мне не надо самому ничего документировать.
GeoNames – это, как говорится, не идеально, но лучшее, что у нас сегодня есть.
Если приложение было одно – вы заменили собственную кустарную (живущую в адресном пространстве конкретного приложения) зависимость – глобальной, стандартизированной, проверенной годами. Что не так уж и плохо само по себе! ;-)
Про Австралию согласен, это так – пример. Про адреса в свободной форме, мне кажется, было бы полезным какой-то умный парсер адресов сделать, который умеет приводить адреса вроде «УЛ НИКИТИНА МОСКВА» в «ул. Никитина, Москва, 125000 Россия». Точно знаю, что некоторым проектам это нужно
Если у меня имеется 5 приложений и всем нужны географические данные, мне проще на всех 5 использовать идентификаторы GeoNames, чем 1) использовать 5 разных наборов 2) придумывать свою конвенцию.
А если выбирать не из своих систем – я не смог ничего глобального найти кроме GeoNames. Если есть что-то еще – то надо будет просто добавить эту систему в пакет, разработчик сможет выбрать, чему он больше доверяет в долгосрочной перспективе :)
А тут в Австралии так вообще — любят принудительное распознавание адреса. Если сайт не смог распознать (интерпретировать) адрес — пользователь не может продолжить. Таким образом, можно использовать подобный пакет без проблем (точнее даже — он уменьшит количество проблем :)
Ещё один плюс GeoNames – идентификаторы уникальны для всей планеты. Необязательно хранить код страны рядом с кодом области.
Плюс всего один — гибкость, можно что-то изменить под себя, добавить. Но это как правило решается через fork или pull request.
У нас были как-то проблемы с библиотекой ZeroMQ, к примеру. Написали автору, заплатили как консультанту — он срочно исправил баг в библиотеке (который видимо больше никого не беспокоил). Даже так получилось быстрее и дешевле, чем свое решение.
У меня ощущение, что нежелание использовать чужое — берет истоки где-то в характере разработчика, это что-то эмоциональное. Тут рациональности нет вообще.
Есть даже термин, популярный сейчас в стартап-сфере — комбинаторная инновация. Не помню, кто первым теорию выдвинул, но суть ее в том, что сначала появляется базовая инновация, а затем на ее основе вырастает множество производных инноваций (в которых по-разному скомбинированы элементы, отсюда и название).
Примеры: электроника в 1920-ых, интегральные схемы в 1970-ых.
Сейчас происходит тоже самое. На одном GitHub находится более 2-ух миллионов репозиториев. Работа современного инноватора (за исключением действительно уникальных, новых функций) — собрать из этих готовых кусков новый продукт, сделать инновацию посредством комбинирования.
Если каждый раз сознательно изобретать велосипеды — об Agile/Lean разработке можно просто забыть. Это очень дорого и неэффективно.
Я согласен, что это нерационально во многих случаях. Просто это будет работать, если кому-то уж сильно так надо :)
Имеется оригинальный сервер с контентом, имеется сеть пограничных серверов (с функцией перевода), которые контент распространяют.
CloudFlare – это CDN, который умеет оптимизировать картинки, минимизировать JavaScript, вставлять Google Analytics. Тут предлагается CDN, который умеет парсить HTML/JavaScript и заменять в нём тексты.
Цепочка CF<->переводчик упомянута только для подчеркивания гибкости, поддержки legacy клиентов и так далее. Это не является рекомендацией, просто это работает.
Термин использован правильно!
Можно добавить на стороне CDN возможность выгрузки всех переводов в удобных форматах, чтобы уверить пользователя, что его не привязали. Захотел – сделал себе экспорт в текстовые файлы и ушёл.
Контроль, кстати, не полностью теряется. Предполагается, что клиент может через панель управления контролировать все переводы, оспаривать варианты, требовать повышения качества и так далее. Клиент всегда прав, CDN просто пытается сделать его жизнь проще.
Пользователи, которые любят CF и лояльны к нему, остаются как: CF – translator – origin, а кто-то кто нашёл сервис отдельно и не знает про CF может просто: translator – origin
Схема translator – CF – origin просто как пример была дана, как доказательство, что по большому счету – разницы то нет откуда вернулся HTML контент, его можно перевести. Это нерационально, но это гибкость дает
С другой стороны, этот пост-рендерный взгляд на ресурс позволяет нормально переводить тексты из БД, а не из словарей. Скажем, у нас онлайн-магазин, и мы хотим показывать "Матрёшка" как "Babushka" на английском сайте. Большинство разработчиков сейчас добавят дополнительное значение где-то в хранилище данных, таким образом далее усложняя локализацию – теперь у нас часть переводов в файлах, часть в базах.
А с точки зрения CDN – это обыкновенный текст, переводить и редактировать его можно вместе со всем остальным. Мне кажется, это достаточно удобно.
2) Смысл статьи – предложить новый метод локализации, который сейчас практически не используется вообще никем.
3) Тут Вы неправильно немного поняли концепцию, и частично виноват я сам. У каждого переведенного сайта отличаются адреса всех страниц. На выбор пользователя – это может быть домен, может быть URI.
Неважно куда приходит запрос на, скажем, site.es/index – на CloudFlare, CloudFont, CDN77 или мой собственный edge-сервер. Адрес site.es/index уникально идентифицирует конкретную страницу на конкретном языке.
1) Если правильная конвенция по именам в CSS — верстка ничего ломать не будет. Если конвенции нет, то при смене дизайна или верстки достаточно в правилах адреса переписать.
2) Во-первых, это вполне себе решается в данной модели. Во-вторых, таких сценариев достаточно немного и они повторяются от сайта к сайту — вероятно, можно сделать какое-то общее решение.
3) Тоже самое, что в 2.
4) Если подобные слова используются где-то по отдельности, не как часть фразы – это может быть проблемой. Но думаю, что можно найти рациональное решение.
Перевод от API — за ним можно ставить онлайн-рынок переводчиков вроде Gengo, там качество контролируется, можно закреплять конкретных переводчиков, оспаривать тексты и так далее. Скорее всего, спустя месяц работы у большинства клиентов проблема отпадет — переводчики привыкнут к требованиям