Comments 15
Давненько я такого не видел
global $db, $syslang;
Я тоже недавно делал локализацию на сайте. Остановился на таком способе:
Для локализации объектов:
И такая таблица для локализации самого сайта:
Подробнее (для asp.net mvc)
Для локализации объектов:
И такая таблица для локализации самого сайта:
CREATE TABLE [dbo].[LocalizedViews](
[Id] [int] IDENTITY(1,1) NOT NULL,
[LanguageId] [char](2) NOT NULL,
[ViewPath] [varchar](50) NOT NULL,
[KeyName] [varchar](50) NOT NULL,
[Value] [text] NOT NULL,
[UpdatedAtUTC] [datetime] NOT NULL,
)
Подробнее (для asp.net mvc)
А если не секрет, сколько процентов пользователей помогают с переводом? и сколько было примерно текстов/элементов для перевода и сколько из них переводили другие люди?
То есть интересна полезность инструмента и возможности такого подхода для еще, как показалось, не самого популярного продукта в мире. Надеюсь, мировая слава у Вас еще впереди! :)
То есть интересна полезность инструмента и возможности такого подхода для еще, как показалось, не самого популярного продукта в мире. Надеюсь, мировая слава у Вас еще впереди! :)
Понятное дело, что пользуюсь пока я один, хотя вот вижу накидали несколько «переводов». Речь же не об этом шла. У меня реализация не заняла много времени, посмотрел сейчас — все утилиты и скрипты уложились в 1000 строк. Сам результатом доволен, если кто-нибудь что-то для себя возьмет, то хорошо.
Некоторые переводы я заказывал, поэтому сам эммулировал работу пользователя. Сейчас уникальных идентификаторов больше 300, из них 200 для проекта (JSON), а остальное для сайта. Пока только два языка русский и английский.
Некоторые переводы я заказывал, поэтому сам эммулировал работу пользователя. Сейчас уникальных идентификаторов больше 300, из них 200 для проекта (JSON), а остальное для сайта. Пока только два языка русский и английский.
Так как мне нужна возможность вставки ресурсов в другие ресурсы, то я добавил макросы вида #идентификатор#Как по мне — экономия на спичках и ненужное усложнение.
Ну и использовании базу не айс.
А почему использование базы — не айс? Или дело в архитектуре?
А почему использование базы — не айс?Потому что оно излишне для этой задачи.
В базе стоит хранить то, что там должно хранится: данные (например, вариант статьи на другом языке).
А для интерфейсных текстов вида «Укажите свое Имя» давно придуманы языковые файлы и средства коллективной работы над ними.
В случае языковых файлов становится невозможно быстро онлайн из интерфейса сайта изменить перевод или строчку на сайте. А по опыту — гораздо удобнее делать это через интерфейс, нежели копаться в файле.
В случае языковых файлов становится невозможно быстро онлайн из интерфейса сайта изменить перевод или строчку на сайте.Эмм… А вы часто/постоянно переводите интерфейсный текст?
А по опыту — гораздо удобнее делать это через интерфейс, нежели копаться в файле.Повторюсь еще раз — есть достаточно средств для комфортной работы с языковыми файлами.
Если вы не знаете других способов правки, кроме ковыряния в файле, то кто в этом виноват?
У меня стоит похожая проблема — перевод языковых файлов силами пользователей. Я искал в инете удобные для простого пользователя средства групповой работы. То ли искал не то, то ли искал не так — ничего не нашел даже минимально подходящего. Может быть вы подскажете какие-нибудь инструменты или хотя бы в каком направлении искать? Я был бы вам очень признателен.
Sign up to leave a comment.
Как я реализовал мультиязычность на сайте и в проекте