У меня есть объект, который уже содержит довольно длинный список свойств, и он будет только расти. Я ищу альтернативу простому добавлению нового свойства каждый раз, когда оно необходимо, но я не уверен, что есть альтернатива, которая не только удобна для разработчиков, но и пользователи, не разбирающиеся в технологиях, могут легко вносить изменения/дополнения.
Я создал небольшую версию своего сценария, которая должна объяснить, что происходит.
const titles = {
fr: 'Some text in french',
fi: 'Some text in finnish'
// tons more properties
}
const locale = window.location.url.split('/')[3] // determines locale to use
const titleElement = document.querySelector('.title')
titleElement.innerText = titles[locale] | 'Some text in english' // sets the titles text
Некоторый контекст был бы полезен.
titles
во фрагменте кода.Здесь немного не хватает контекста. Почему непрограммисты вносят изменения в ваш код JavaScript? В любом случае, не зная много о вашей настройке, возможно, вы могли бы хранить эти данные в базе данных, а не жестко закодировать в приложении? И затем вы могли бы предоставить небольшой пользовательский интерфейс для других людей, чтобы поддерживать данные по своему усмотрению, без фактического изменения файлов кода. Возможно, вы даже сможете найти шаблон для такого интернационализированного хранилища данных и код приложения для его поддержки. Это довольно распространенное требование
Это должно быть на стороне клиента? Вы всегда можете сохранить записи в базу данных и просто получить языковые данные в зависимости от выбранного пользователем языка. Таким образом, людям, не разбирающимся в технологиях, будет легче поддерживать и расширять систему. Вам просто нужно создать для них интерфейс, чтобы добавить языковой текст.
Вы переросли ручное редактирование файлов. Как и все приложения... масштабирование включает в себя адаптацию процессов
«не технически подкованные пользователи» не должны редактировать код. Вместо этого вы должны предоставить им возможность вводить данные в ваше веб-приложение, а затем хранить их более постоянно на сервере. Затем веб-приложение считывает эти данные, когда они запрашиваются, и что-то с ними делает.
Я полностью с вами согласен, но клиент использует Adobe Target для своего проекта, и я не вижу ничего, что позволило бы ему получить доступ к внутренним переменным из простого пользовательского интерфейса на панели управления Target. Мне нужно еще немного покопаться, чтобы убедиться.
@BrandonBenefield в какой-то момент наступает время обсудить проблемы, которые может вызвать их процесс, и его ограничения. Если у них есть существующий веб-сайт, вы всегда можете убедить их, что пришло время внедрить языковой редактор в их CMS и просто подключиться через ajax в Adobe Target.
«позволяет им получать доступ к внутренним переменным из простого пользовательского интерфейса». Для меня это звучит как неправильный подход к разработке программного обеспечения. Сбор требований должен быть о том, чего хочет пользователь, на языке предметной области пользователя, а не на языке компьютерного программирования. Это означает, что такие вещи, как «доступ к внутренним переменным», не должны быть частью разговора. Вместо этого разговор должен быть типа "когда я нажимаю на... должно делать...".
Являются ли все ваши имена свойств языковыми кодами (ne, de, se, en, it, es, pt, pl, ....)?