2010-06-03 1 views
35

Я знаю, что на момент написания этой статьи только Opera поддерживает интерфейс браузера дляЕсть ли способ, чтобы локализовать входной тип = «дата» в HTML5

<input type="date" name="mydate"> 

и, возможно, мои попытки локализовать это поле было встретили разочарование, потому что тонкости, подобные локализации, еще не были включены в их реализацию, но я даже не упоминаю об этом в спецификации HTML5. Можно ли указать локализацию? Должен ли я делать lang = "fr" в родительском элементе?

Некоторые замечания по реализации обсуждаемого сайта:

  • локализация (язык) явно подобран пользователем, потому что они управляют данными на нескольких языках, и это не разумно ожидать, что браузер пользователя chrome находится на просматриваемом языке или что браузер предоставляет заголовки запросов желаемого языка.
  • Я хочу быть уверенным, что если страница будет отображаться на французском языке, то выбор даты, предоставляемый браузером хром, показывает варианты, которые имеют смысл для французского языка.
  • Плана падать обратно jQueryUI для браузеров, которые не поддерживают тип = «дату», я буду использовать механизм обнаружения, представленный в Dive into HTML 5

ответ

13

Из того, что я знаю, мышление за то, что мы делаем в Opera (полное раскрытие: я работаю для них) заключается в том, что сборщик дат - это почти расширение хром, основанный на браузере. Таким образом, он будет локализован в соответствии с языком браузера, а не языком просматриваемой страницы.

+4

3 проблем с этим: 1. Это сотрясение как пользователь, чтобы иметь для переключения языков (хром против содержания) для выбора даты. 2. Данные будут отображаться на странице в локали, будет ли хром (в английском режиме) понимать французов и что Juin означает июнь? 3. Серверная сторона ожидает, что данные будут отформатированы в локали и соответственно проанализированы, если сборщик данных будет форматировать дату для ожидаемого языкового стандарта, сервер будет неверно истолковывать его. Эти проблемы не ограничиваются датами. Как насчет чисел? Французский использует запятую вместо десятичной. Как будет обрабатывать хром? Подход кажется недальновидным. – lambacck

+5

1 он действует как, скажем, ввод типа файла во всех браузерах ..., который также локализуется в соответствии с языковой версией браузера, а не с страницей. я могу видеть аргументы за и против этого. 2 не совсем понимают, что вы имеете в виду здесь, если предположить, что это относится к 3 независимо от того, как отображается пользовательский интерфейс для датпикера, конечный результат (который затем передается серверу) всегда находится в том же формате ISO, независимо от того, язык, отображаемый пользовательским интерфейсом. не пробовал число вещей (предполагая, что вы имеете в виду тип ввода = «число») ... но здесь я вижу, что у него действительно будут потенциальные проблемы. не знаю, если это локализовано в настоящее время, tho. –

+0

Я не думаю, что формат ISO является разумным ответом для прогрессивного улучшения. Если браузер возвращается в равное поле ввода, и у них нет включенного Javascript (да, эти люди существуют), они должны будут ввести дату в формате ISO? Если пользователь не является техническим, маловероятно, что они захотят ввести дату в формате ISO (даже знать, как). – lambacck

11

Я согласен с lambacck. В настоящее время я пишу Javascript-код, чтобы сделать новые функции формы доступными кросс-браузер, используя jQuery UI для этого.

Я работаю в Люксембурге, что является хорошим местом, чтобы более подробно проиллюстрировать проблему локализации.

Большинство сайтов, которые мы пишем, являются многоязычными de | fr | en. Из нашей статистики мы можем сказать, что люди используют языковой переключатель на сайте для отображения своего предпочтительного языка, но этот выбор редко соответствует предпочитаемому языку браузера.

Если локаль поля календаря и т.д. осуществляется с помощью операционной системы, это возвращает нас к несчастному < ввода   типа = файл > ситуацию, когда метка читает Загрузить файл и кнопка говорит Parcourir. Вы ничего не можете сказать об этом языковом миксе, и я всегда считал это серьезным раздражением.

Заключение Я должен перезаписать календарь по умолчанию с помощью jQuery, чтобы убедиться, что он делает то, что я хочу.

На мой взгляд, настраиваемый API или, по крайней мере, способ манипулировать языковой версией на уровне HTML был бы замечательным. Поскольку новые типы полей еще не получили широкого распространения другими производителями браузеров, я предполагаю, что этот вопрос все еще можно принять во внимание.

Спасибо за это.

+0

», где этикетка читает« Загрузите файл, а кнопка говорит «Parcourir»: это просто означает, что ваше приложение не уважает язык браузера пользователей ... – feeela

+6

@feeela: Что делать, если на вашем сайте есть языковой выбор, чтобы пользователь мог переопределить по умолчанию (с учетом браузера) язык ... – fretje

3

Для мобильных устройств лучшим решением, которое мы нашли, является использование ввода текста для ввода даты, рядом с которым расположен значок календаря, который имеет невидимый ввод даты над значком.

Преимущества:

  • работает на всех браузерах и устройствах
  • можно использовать следующую кнопку в курсе прошивкой (если несколько полей)
  • пользователь может ввести дату (очень полезно)
  • Избегает iOS UI-ошибки (1. редактирование существующих данных с пустой датой, рядом с датой, значением даты установлено сегодня - arrrgh, 2. показ клавиатуры, следующий в дату, всплывающие окна и клавиатура исчезает - ouch)
  • использовать библиотеку датчтобы показать дату во вводе как локализацию, установленную для учетной записи пользователя (а не в браузере), и можете использовать интеллектуальную библиотеку дат (введите «завтра» и т. д.).
  • нажмите значок календаря, чтобы увидеть дату локализации браузера
  • изящного запасной вариант, даже если input type=date не поддерживается устройство/браузер (например, некоторые Android устройство не поддерживает дату или серьезные ошибки).
  • для настольных ПК (обнаруженных без поддержки прикосновений), мы показываем наше собственное выпадающее меню даты.

HTML является чем-то вроде:

<input type=text> 
<span style=position:relative> 
    <input type=date class=date-input tabIndex=-1> 
    <div class=date-input-icon>&#x25BC;</div> 
</span> 

CSS:

.date-input { 
    position: relative; 
    z-index: 1; 
    webkit-appearance: none; 
    display: inline-block; 
    opacity: 0; 
    width: 1em; 
} 

.date-input-icon { 
    position: absolute; 
    right: 0; 
    width: 1em; 
} 
+1

Вопрос о локализации не касается других проблем, связанных с использованием виджета native type = date. В ответе не упоминается локализация. – lambacck

+0

Ничего, я вижу часть локализации, которая использует javascript (это уже принятое решение). – lambacck

+0

В чем преимущество ввода скрытой даты, а не просто использования типа = текста, когда кнопка предоставляет пользовательский интерфейс выбора. – lambacck