Ваша вимога:
для того, щоб мій сайт працював на кількох мовах
як аутентифікований користувач
мені потрібно мати можливість перекладати одразу будь-які та всі дзвінки перекладу, знайдені в кодовій базі мого сайту, які були виконані за допомогою функції t ().
Чи опис цієї вимоги навіть близький до того, що ви просите?
Гусениці
Як хтось сказав, - сканер теоретично міг пройти весь сайт, щоб змусити реєстрацію всіх t () дзвінків. Але 1) сканер не знає, які сторінки сканувати; 2) ми не прагнемо підтримувати список сторінок для сканування, тому; 3) ми не хочемо використовувати сканер, період. Eww. Просто, eww. Правильно?
Проблема
- У нас немає списку всіх рядків перекладу.
- Drupal / PHP - це динамічна мова на відміну від C, яка складається. Тому ми не можемо сказати, наприклад: скомпілюйте всю цю кодову базу, потім знайдіть мені всі екземпляри цієї функції
t(), потім зареєструйте ці екземпляри в базі даних, а потім перекладіть всі ці зареєстровані екземпляри за t()один раз. Я не думаю, що це варіант, який ми маємо на своєму столі.
- Інструмент аналізу статичного коду був би безпорадним з тієї ж причини, коли сканер був би безпорадним. Я знайшов це
t()в цьому файлі. Чудово! У якій URL-адресі він використовується? Який контекст?
Намагання на проблему з поточними інструментами (Drupal та деякими модулями contrib) та поточними обмеженнями (спираючись на виклики тем у режимі реального часу -> шаблонні файли -> t()виклики) виглядає як алея без виходу тут. Нам може знадобитися трохи подумати поза коробкою.
Що нам потрібно
- Нам потрібне джерело даних, модель, яка підказує мені, які поточні рядки перекладу у нас є, і який їх контекст -
- Проактивна модель даних. Поточна модель даних реагує (модель оновлюється щоразу, коли відбувається виклик
t()). Нам потрібна проактивна модель даних - така, в якій програма піклується про пошук t()екземплярів, перш ніж їх реально виконати клієнт.
- Нам потрібен контекст.
t()поодинці це не скорочує, тому що - ми не знаємо, що ми перекладаємо "foo", але мова перекладу, яку ми перекладаємо, залежить від URL-адреси, де t()відбувається. Навіть якби ми могли жорстко кодувати цільову мову під час t()виклику, скажімо, використовуючи обгортковий виклик, це не працює для ваших цілей.
Я визначив деякі інструменти, які - якби ми їх мали - допомогли б нашій проблемі. За допомогою цих інструментів ми могли б увійти в модель даних і сказати: дайте мені всі рядки, вкладені в нихt() які ще не були заповнені. Тепер вставити ці переклади. Дякую.
І наступного разу, коли замовник приходить, переклади є на місці.
Як би ми ... побудували ці інструменти?
Обмеження
- Цільова мова не може бути в шаблоні, який визначається URL-адресою. Припускаючи, що рядок повинен підтримувати будь-яку мову.
- Перекладена рядок не може бути в шаблоні. Переклад розміщуватиметься в базі даних.
Тепер, коли я більше роздумував над проблемою та виявив деякі проблеми та обмеження, я можу подумати про те, щоб знайти будь-які рішення, наявні там, або зробити будь-які власні рішення.
Рішення мозкового штурму
Мені потрібно щось, що пов’язує "все" разом. А як ... сутність?
- Суб'єкт господарювання може зберігати продукт, який потрібно перекласти.
- Суб'єкти можуть забезпечити співвідношення - клей - між продуктом, який потрібно перекласти, та його контекстом.
- Суб'єкт може вказати, скажімо, у полі місцезнаходження URL-адреси за замовчуванням продукту.
- Маркери можна використовувати для визначення альтернативних місць (мов?), На яких продукт з’явиться.
- Організації надають нам проактивну модель даних, яка нам потрібна, і це контекст. Що в свою чергу дозволяє нам робити такі речі, як: зайти в базу даних, захопити всі сукупності продукту, а якщо немає рядка перекладу для полів X, Y і Z, створити ці рядки перекладу.
Коли клієнт потім захопить /pl/product/200, ви відправляєтесь у db, шукаєте продукт 200 та захоплюєте вже існуючий plпереклад. У вас також є поле заголовка та підпису для цього продукту? Переклади повинні бути і там.
Зауважте, що я тут дуже розпливчастий і загальний щодо того, який модуль перекладу ви використовуєте. Ви могли б дуже добре використати власний модуль перекладу - швидше за все, це так. Усі моделі перекладів, які я бачив в Drupal досі (станом на D7, ще не дивилися на D8), є реактивними, не ініціативними.
Коротко
Теоретично інструменти для побудови того, що вам потрібно, є сутностями, що є ключовим компонентом, який би поєднав все разом: - дані (рядок перекладу), - цільові мови. Не обов'язково бути в самій сутності, бажано лексики таксономії, скажімо, для мов продукту. а може бути, загальна таксономія і для інших суб'єктів. - Контекст. URL-адреса, за якою відображається сутність. URL-адреса міститиме маркер, а маркер у свою чергу посилається на таксономію цільової мови.
За допомогою цих трьох інгредієнтів ви можете сказати: Захопіть усі productсутності, перейдіть у URL aliasполе, отримайте маркер таксономії , пройдіть усі можливі комбінації термінів, подайте всі комбінації поточному користувачеві, використовуючи або дуже велику потворну форму - або, AJAX - і багатоступінчасті форми (щось подібне), і коли поточний користувач перекладає різні мови для продукту 200, збережіть їх десь у базі даних
Десь у базі даних може бути поле Field API в сутності, поле налаштувань, що належить кожному об'єкту (не саме Field Field API, але воно все ще може зберігати дані), або окрема таблиця, яку ви використовуєте для цього. Я думаю, що збереження даних в Entity дозволило б зберегти і код, і дані акуратніше та простіше.
Побудова: можливі рішення
- D8MI (багатомовна ініціатива Drupal 8)
- Спеціальний код: "індексувати" переклади, доступні в шаблонах t () шляхом програмного запиту та рендерінгу доступних пакетів та їх пов'язаних реалізацій.
Псевдокод
Отримати сутність (типу x),
Знайти всі мови (систематика або основна мова, пов'язана з продуктом),
Візуалізувати сутність,
- щоб виявити це рядки перекладу t ()
- рендер викликів тема (), яка обробляє багатомовний шар презентації продукт, а не сама модель даних про продукт.
Результат:
- Перший виклик для відображення шаблону сутності на кожній мові повертає реалізацію мови за замовчуванням для кожного виклику.
- Параметри t () в шаблоні тепер кешуються в Drupal та готові до перекладу (для кожного мовного екземпляра, а не для кожного екземпляра продукту).
- Користувач з роллю «перекладача» тепер може перейти до інтерфейсу перекладу та перекласти всі доступні параметри t () для кожної мови.
- Власнику сайту не потрібно чекати, коли клієнти відвідують кожну сторінку продукту або відвідують кожну сторінку продукту вручну, оскільки це було зроблено для нього програмно.
Відкриті запитання:
- Що таке контекст? Якщо я здійснюю програмний дзвінок на тему () для кожного пакета об'єктів "продукт", чи записує він місце, з якого було здійснено дзвінок? Чи записує він URL-адресу вузла? Чи можна змінити “контекст”? Де записаний контекст? Що відбувається, коли у вас є "динамічні" шаблони, тобто коли у вас є більше одного шаблону на продукт і як ви збираєтесь виявляти ці варіанти?
Як завжди, теоретизування та псевдокод корисні лише для мозкового штурму. Але в розвитку ми навряд чи дізнаємося проти чого насправді, поки не почнемо розробляти прототипи. Отож, склавши пару обмежень, можливих рішень та можливих проблем чи питань - я зараз можу приступити до впровадження доказу концепції чи діючого прототипу. На деякі відкриті вище питання можна відповісти лише таким чином, і якнайшвидше ми прототипуємо (незалежно від успіху чи невдачі), ми можемо почати відповідати на деякі з цих питань - або взагалі змінити підхід. Слідкуйте за налаштуваннями ~
wgetабо будь-якого іншого. Хакіш, але ти сказав, що це було дозволено (: