I'm building a restaurant website for a client using HTML, vanilla CSS, vanilla JavaScript, vanilla PHP, and MySQL. The client wants the menu items, events, buttons, and general website content available in three languages. They also want to manage the content through an admin panel, so that when they add a new menu item in the future, its name and description can be translated automatically and displayed in the selected language. I'm unsure how to structure the database, admin panel, and translation workflow, and this is my first time implementing website localization.
3 Answers
Separate the site’s fixed interface text from database content. Store translations for labels such as buttons and navigation in language files, then choose the correct file based on the visitor’s selected language. For menu items and events, use a language column or, preferably, separate translation records linked to the same item. For example, a menu item can have one shared price and multiple translated name and description records. The admin panel can let the client enter the original content, select the target languages, and save or request translations for each one.
You can connect a translation API from your PHP backend when a new item is created or when the client clicks a translate button. Send the source text and target language to the service, then save the returned translations in MySQL. Do not call the translation service directly from browser JavaScript because that would expose your API key. Also add an option for the client to edit the generated translation before publishing it.
Automatic translation is convenient, but it can produce awkward or incorrect wording, especially for food names, allergens, and culturally specific descriptions. Treat the generated result as a draft and allow manual review. A professional translation service may be safer for the most important content.
Look into internationalization and localization libraries for the language-selection and formatting parts of the project. The general pattern is to keep a default language, detect or let the visitor choose another language, and fall back to the default whenever a translation is missing. For database content, a structure such as menu_items and menu_item_translations works well: menu_items stores shared fields like price and availability, while menu_item_translations stores item_id, language_code, translated_name, and translated_description. The same pattern can be used for events and other editable content.
Make sure prices and other non-language values are not translated as text. Store the price as a numeric database value and format it according to the selected locale. Translate only fields such as names, descriptions, labels, and event details.