Формат ссылки для интернационализировавшего веб-приложения?
PipedInputStream и PipedOutputStream должен только использоваться, когда у Вас есть несколько потоков, как отмеченный Javadoc.
кроме того, обратите внимание, что входные потоки и потоки вывода не переносят прерываний потока с IOException с... Так, необходимо рассмотреть слияние политики прерывания к коду:
byte[] buffer = new byte[1024];
int len = in.read(buffer);
while (len != -1) {
out.write(buffer, 0, len);
len = in.read(buffer);
if (Thread.interrupted()) {
throw new InterruptedException();
}
}
Это было бы полезным дополнением, если Вы ожидаете использовать этот API для копирования больших объемов данных или данных из потоков, которые застревают в течение невыносимо долгого времени.
9 ответов
Я бы не стал выбирать вариант 1, если ваши страницы общедоступны, т. Е. Вам не требуется входить в систему для просмотра страниц. Причина в том, что поисковая система не будет сканировать разные языковые версии страницы. The same reason goes agains option no 5. A search engine is less likely to identify two pages as separate pages, if the language identification goes in the query string.
Lets look at option 4, placing the language in the host name. I would use that option if the different language versions of the site contains completely different content. On a site like Wikipedia for example, the Greek version contains its own complete set of articles, and the English version contains another set of articles.
So if you don't have completely different content (which it doesn't seem like from your post), you are left with option 2 or 3. I don't know if there are any compelling arguments for one over the other, but no. 3 looks nicer in my eyes. So that is what I would use.
But just a comment for inspiration. I'm currently working on a web application that has 3 major parts, one public, and two parts for two different user types. I have chosen the following url scheme (with en referring to language of course):
http://www.example.com/en/x/y/z for the public part.
http://www.example.com/part1/en/x/y/z for the one private part
http://www.example.com/part2/en/x/y/z for the other private part.
The reason for this is that if I were to split the three parts up into separate applications, it will be a simple reconfiguration in the web server when I have the name of the part at the top of the path. E.g. if we were to use a commercial CMS system for the public part of the site
Edit: Другого аргумента против варианта нет. 1 состоит в том, что если вы слушаете ТОЛЬКО accept-language, вы не даете пользователю выбора. Пользователь может не знать, как изменить язык, установленный в браузере, или может использовать настройку компьютера на другом языке. Вы должны хотя бы предоставить пользователю выбор (сохранить его в файле cookie или профиле пользователя)
Номер четыре - лучший вариант, потому что он определяет код языка довольно рано. Если вы собираетесь предоставлять какие-либо переадресации, всегда используйте тег канонической ссылки.
Мой собственный выбор №3: http://domain.com/el/folder/page . Кажется, это самый популярный в сети. У всех других альтернатив есть проблемы:
http://domain.com/folder/page--- Плохо для SEO?http://domain.com/folder/page/el--- Не работает для страниц с параметрами. Это выглядит странно: ... page? Par1 = x & par2 = y / elhttp://domain.com/el/folder/page--- Выглядит хорошо!http: // el. domain.com/folder/page--- Для развертывания требуется больше работы, так как для этого требуется добавление поддоменов.http://domain.com/folder/page?hl=el--- Плохо для SEO?
Это зависит от обстоятельств. Я бы выбрал номер четыре лично, но у многих успешных компаний есть разные способы достижения этого.
- Википедия использует субдомены для различных
языки (el.wikipedia.org).
- То же самое делает Yahoo (es.yahoo.com для испанского), хотя он не поддерживает греческий.
- То же самое делает Gravatar (el.gravatar.com)
- Google использует каталог / intl / el /.
- Apple использует каталог / gr / (хотя и на английском языке и ограничен страницей iPhone)
Это действительно зависит от вас. Как вы думаете, что больше всего понравится вашим клиентам?
Я бы выбрал номер 3 , перенаправил на http://example.com/el/folder/page , потому что:
- Выбор языка более важен, чем выбор страницы, поэтому выбранный язык должен быть первым в истинно читаемом человеком URL.
- Только один домен получает весь PR Google. Это хорошо для SEO.
- Вы можете рекламировать свой сайт локально с помощью встроенного языкового кода. Например, в Греции вы должны рекламировать как
http://example.com/el/, чтобы каждый местный посетитель попадал на сайт в Греции и избегал разочарования при выборе языка.
В качестве альтернативы вы можете выберите номер 5 : это хорошо для Google и друзей, но не так приятно для пользователя.
Кроме того, мы должны воздерживаться от перенаправления пользователя куда-либо, если это не требуется. Таким образом, на мой взгляд, пользователь открывает http: // example.
Ни один из них. «Обычный пользователь» не поймет (и не запомнит) ни одно из этих сокращений.
В порядке предпочтения я бы предложил:
Выберите вариант 5, и я не считаю, что это плохо для SEO.
Параметр hl должен иметь приоритет над заголовком Accept-language , чтобы пользователь мог легко управлять этим вопросом. Заголовок будет использоваться только при отсутствии параметра hl . Разрешенная привязка из-за этого немного усложняется, и, вероятно, ее следует адресовать через файл cookie, который будет поддерживать перенаправление на язык, выбранный параметром hl (поскольку он мог быть изменен пользователем из Параметр Accept-language или обработка всех ссылок на странице для добавления в текущий параметр hl .
Проблемы SEO можно решить, создав файлы индекса для все, как это делает stackoverflow, может включать несколько наборов индексов для разных языков, Надеюсь, обнадеживает появление в результатах для нестандартного языка.
Использование 1 убирает дифференциатор в URL. Использование 2 и 3 предполагает, что страница отличается, возможно, помимо языка, как в Википедии. А использование 4 предполагает, что сам сервер разделен, возможно, даже географически.
Поскольку существует удивительно слабая корреляция географического положения с языковыми предпочтениями, вопрос предоставления географически близких серверов следует оставить на усмотрение надлежащей настройки CDN.
3 или 4.
3: С этим легко справиться с помощью htaccess / mod_rewrite. Единственным недостатком является то, что вам придется написать какой-нибудь метод автоматического внедрения языкового кода в качестве первого сегмента URI.
4: Вероятно, лучший метод. Используя заголовки хоста, все это можно отправить в одно и то же веб-приложение / контент, но затем вы можете использовать код для извлечения языкового кода и перехода оттуда.
Простые. ;)