Meertalige content beheren in PHP: model en redactionele workflow

Een meertalige applicatie bestaat niet alleen uit het vertalen van schermlabels. Als de applicatie ook artikelen, productpagina's of andere redactionele content aanbiedt, moet duidelijk zijn in welke taal de content is opgesteld, hoe de versies zich tot elkaar verhouden en wat het betekent dat een vertaling klaar is voor publicatie. Een onnauwkeurig model leidt uiteindelijk tot verouderde teksten, links zonder bestemming of concepten die worden getoond aan gebruikers die ze niet zouden mogen zien.

Bij het plannen van meertalig contentbeheer in PHP is het verstandig om keuzes voor de interface, gegevens en redactionele workflow van elkaar te scheiden. De implementatie kan gebruikmaken van vertaalbestanden voor de interface en van de database voor veranderlijke content, maar die verdeling moet aansluiten op het domein en op de behoeften van de redacteuren.

Interfacetaal, brontaal en vertaling scheiden

De interfacetaal bepaalt labels, validatiemeldingen, datumopmaak en andere teksten die bij het product horen. In een PHP-applicatie kan dit worden beheerd met vertaalcatalogi, bijvoorbeeld bestanden die per locale zijn ingedeeld, en worden gekozen op basis van een gebruikersvoorkeur of een sessie-instelling. Deze taal mag niet worden verward met de taal van de content die wordt opgevraagd.

De brontaal geeft aan in welke taal een redactioneel item is gemaakt. Elke vertaling is een versie die aan dat item is gekoppeld en heeft een eigen taal. Een gebruiker kan in het Spaans door de interface navigeren en een pagina openen waarvan de oorspronkelijke content in het Engels is; de applicatie moet expliciet bepalen of dat is toegestaan en hoe dit wordt gemeld.

Sla genormaliseerde taalcodes op en hanteer waar nodig een consistent beleid voor regionale locales. Ga er niet van uit dat taal en land uitwisselbaar zijn: een regionale variant kan invloed hebben op de tekst, maar ook op opmaak, beschikbaarheid of commerciële vereisten. Bepaal welke locales het product ondersteunt en welke worden gebruikt om een onvolledige voorkeur op te lossen.

Een gegevensmodel kiezen dat het domein weergeeft

Er zijn drie gangbare patronen, elk met eigen afwegingen:

• Velden per taal: kolommen zoals title_es en title_en zijn eenvoudig wanneer er weinig talen zijn, de veldenset stabiel is en directe queries nodig zijn. Ze zijn minder flexibel wanneer talen worden toegevoegd en maken elke schemaverandering afhankelijk van de taalcatalogus.
• Onafhankelijke records: elke versie wordt als een afzonderlijk item opgeslagen. Dit kan passend zijn als versies daadwerkelijk onafhankelijke levenscycli of structuren hebben, maar vereist een andere betrouwbare manier om ze te groeperen. Gebruik geen vergelijkbare titel of URL als impliciete koppeling.
• Gerelateerde vertaaltabel: een gemeenschappelijk item wordt gekoppeld aan één rij per taal, bijvoorbeeld via content_id en locale. Zo kunnen eenvoudig talen worden toegevoegd en beschikbare versies worden opgevraagd. Er zijn beperkingen nodig om dubbele vertalingen in dezelfde taal voor één item te voorkomen.

Een gerelateerde tabel is vaak geschikt wanneer versies dezelfde identiteit en structuur delen, maar dat is geen universele regel. Velden die niet worden vertaald — bijvoorbeeld een interne referentie — kunnen in de gemeenschappelijke entiteit blijven; gelokaliseerde redactionele velden horen bij de vertaling. Bepaal ook of een vertaling een eigen URL, zoekmetadata of publicatiedatum mag hebben.

Definieer in de database foreign keys, uniciteit per item en taal, en het gedrag bij het verwijderen van gegevens. De applicatielogica in PHP moet daarnaast valideren of de taal wordt ondersteund en of het gerelateerde item bestaat. Databasebeperkingen beschermen tegen gelijktijdige schrijfbewerkingen en fouten die met alleen een voorafgaande validatie niet worden voorkomen.

Versies koppelen zonder te eisen dat ze allemaal bestaan

Niet elk item bestaat in elke taal en niet alle vertalingen worden op hetzelfde moment afgerond. Modelleer die werkelijkheid: het ontbreken van een rij hoeft geen integriteitsfout te zijn als de vertaling optioneel is. Een redactionele status moet daarentegen aangeven wat er gebeurt wanneer er wel een rij bestaat, maar deze nog niet kan worden gepubliceerd.

Voorkom dat informatie die bij het gedeelde item hoort in elke vertaling wordt gedupliceerd, tenzij variaties nodig zijn voor het domein. Als vertalingen kunnen worden ontkoppeld, verplaatst of als archief bewaard, leg die bewerkingen en de bijbehorende machtigingen dan vast. Gebruik een stabiele relatie om de groep versies te bepalen, geen overeenkomsten in tekst, slug of datum.

Leg bij een wijziging van een vertaling vast welke versie van het origineel als referentie diende, als het team mogelijk verouderde content moet kunnen opsporen. Dat signaal bewijst op zichzelf niet dat de vertaling onjuist is; het helpt om een controle te prioriteren. Voor sommige producten volstaat een markering dat controle nodig is, terwijl andere een versiegeschiedenis en audittrail nodig hebben.

Redactionele statussen per taal definiëren

De publicatiestatus moet bij elke vertaling horen wanneer elke taal onafhankelijk kan worden geschreven, gecontroleerd en gepubliceerd. Een item kan in de ene taal gepubliceerd zijn en in een andere nog een concept zijn. Eén publicatieboolean op itemniveau geeft dat verschil niet weer.

Ontwerp een kleine, expliciete workflow, bijvoorbeeld concept, in beoordeling en gepubliceerd. Bepaal wie elke status mag wijzigen, welke velden verplicht zijn en of beoordeling goedkeuring vereist. De publicatiedatum, de verantwoordelijke persoon en de wijzigingsgeschiedenis kunnen nodig zijn om het proces uit te voeren; voeg geen statussen toe die niet overeenkomen met echte handelingen van het team.

Openbare queries moeten filteren op status en taal; vertrouw er niet op dat de redactionele interface niet-gepubliceerde rijen verbergt. Centraliseer deze regels in PHP in een domeintoegangslaag of herbruikbare queries, en test of controllers, API's en achtergrondtaken ze naleven. Bewerkings- en publicatieacties moeten ook de machtigingen voor de specifieke taal en het specifieke item controleren.

Ontbrekende vertalingen, URL's en zoeken consistent afhandelen

Als een vertaling ontbreekt, zijn er verschillende mogelijke beleidskeuzes. De applicatie kan het item in die taal verbergen, melden dat het alleen in een andere taal beschikbaar is, of een fallback tonen. Kies op basis van het type content en de gevolgen voor de gebruikerservaring; een fallback mag niet worden gepresenteerd alsof het een vertaling is. Als content in een andere taal wordt getoond, geef dat dan duidelijk aan en behoud de mogelijkheid om terug te keren naar de aangevraagde versie.

Hanteer een andere regel voor de interface dan voor content. Dat navigatielabels terugvallen op een andere catalogus betekent niet dat artikelen automatisch door hun oorspronkelijke versie moeten worden vervangen. Een redactionele fallback moet beperkt blijven tot toegestane talen en publiceerbare content, en mag geen concepten teruggeven.

URL's moeten naar een bestaande versie verwijzen of een gedocumenteerde omleidingsregel volgen. Zoek bij het wisselen van taal naar de vertaling van hetzelfde item; als die niet bestaat, bied dan een expliciete uitweg in plaats van een route te maken die geldig lijkt. Voorkom voor SEO dat lege of dubbele pagina's worden gepubliceerd door onzichtbare fallbacks. Zoeken mag alleen geschikte versies indexeren en moet de bijbehorende taal gebruiken om resultaten te filteren en weer te geven.

Checklist vóór publicatie

• Zijn de interface, de brontaal en de taal van elke vertaling in het model afzonderlijke concepten?
• Wordt voorkomen dat twee vertalingen van hetzelfde item in dezelfde taal worden opgeslagen?
• Kan een vertaling ontbreken zonder een inconsistente status te veroorzaken?
• Kan het team per taal onderscheid maken tussen concept, beoordeling en publicatie?
• Controleren openbare routes en links om van taal te wisselen of er een zichtbare versie bestaat?
• Is de fallback per gebruikssituatie gedefinieerd, wordt deze aan de gebruiker gemeld en worden concepten nooit getoond?
• Filtert zoeken op taal en status, en stopt het met indexeren van een ingetrokken versie?
• Zijn machtigingen, gelijktijdig bewerken, verwijderen, onvolledige content en taalwisselingen getest?

Test ook het intrekken van een vertaling waar al links naartoe verwijzen, het bijwerken van het origineel nadat een versie is gepubliceerd en het rechtstreeks opvragen van een niet-beschikbare URL. Controleer in elk geval de response, de navigatie en de zichtbaarheid in zoekresultaten. Het doel is niet om alle talen in hetzelfde tempo te laten verlopen, maar om elke versie een eigen identiteit en een verifieerbare status te geven, met voorspelbaar gedrag voor redacteuren en gebruikers.