Translatable modules/Proposed solutions/nl
Het project Translatable modules probeert een een nieuw framework te maken voor het vertalen van modules.
Er zijn meerdere voorstellen voor een oplossing voor de opslag in de discussie gebracht.
Een van de hoofddoelen van deze consultatie is het beslissen welke van deze voorstellen wordt geïmplementeerd en aan de module-bouwers wordt aanbevolen.
Vertaalbare pagina
Beschrijving
Iets als Module:ModuleMsg op Meta gebruiken, maar dan gestandaardiseerd:
- Zet alle berichten op een voor vertaling gemarkeerde gewone wikitext pagina.
- Maak standaard Lua functies om ze te laden (eerder dan een module als Module:ModuleMsg op elke wiki).
Voordelen
- Het voor vertaling markeren van pagina's is iets vertrouwds voor vertalingenbeheerders.
- Het werkt ook voor sjablonen.
- Elke vertaling is een wiki-pagina. Het is goed voor de credit, geschiedenis, gescheiden verwerking, enz.
Nadelen
- De markering van een vertaaleenheid is een getal. Door getallen als keys voor de teksten te gebruiken wordt de code onleesbaar. Het is zoals hierboven aangegeven mogelijk om de getallen door teksten te vervangen, maar dat is in de extensie Translate matig gedocumenteerd. De documentatie van deze functie zou dus wat aangepast moeten worden.
- Het is onduidelijk hoe de parameters ($1, enz.) en andere wiki syntaxis i18n functies (GENDER, PLURAL, enz.) werken. Ze hoeven nu niet compatibel te zijn met wikitext pagina's.
- Dit kan op een wiki werken voor de module localization, maar hoeft niet te werken als de modules globaal worden.
- Er is een oplossing nodig om de pagina's op te zoeken die vertaald moeten worden. Op dit moment toont de selectie van de berichtengroepen alle vertaalbare pagina's.
- In de tijd van globale modules en sjablonen is het onduidelijk hoe het lokaal wordt aangepast op de wiki's.
- Mogelijk problemen met de performance als elke vertaling per keer wordt geladen en het afhandelen van het terugvallen als de vertaling niet lukt. Er is een Action API
messagecollection, maar geen mooie Lua of Wikitext API voor het laden van vertalingen.
JSON .tab file in the Data namespace on Commons
Description
Use something similar to what Module:TNT is doing, but formalized:
- Plaats alle bronberichten in een JSON-bestand in de Data namespace op Commons in het “banana” formaat, zoals in MediaWiki extensies, met qqq voor documentatie.
- Deze syntaxis kan ook worden gebruikt voor core en extensie teksten.
- Voeg aan de extensie Translate toe het laden van de bronberichten en het schrijven van de vertalingen per taal naar JSON-bestanden.
- Voeg Lua functies toe aan de standaard Scribunto bibliotheek om de berichten te laden.
- Gebruik een ander JSON-bestand voor het organiseren van de vertaalbare bestand voor het in Translate gebruikersvriendelijker tonen van de selectie van de berichtengroep.
Voordelen
- Het bestandsformaat is gelijk aan dat bij extensies.
- Deze pagina's zijn voor modules al globaal benaderbaar.
- De pagina's zijn in ruwe vorm eenvoudig benaderbaar voor JavaScript gadgets, die het JSON-bestand omzetten in een intern object dat alle verlangde vertalingen bevat. Er kan een API nodig zijn om een enkele taal op te halen of voor het terugvallen, wat het netwerkverkeer verbeterd. JavaScript gadgets hebben het liefst een enkele opdracht om alle vertalingen op te halen die dan in de client cache komen te staan.
Nadelen
- Er moet ondersteuning voor een nieuw bestandsformaat (FFS) worden ontwikkelt en onderhouden in de extensie Translate. Wij hebben en nieuw type MessageGroup nodig zowel als voor MessageLoading.
- In de tijd van globale modules en sjablonen is het onduidelijk hoe het lokaal wordt aangepast op de wiki's.
JSON-bestand in een MCR-slot
Beschrijving
Dit is gelijk als bij het bestand “JSON .tab in de Data namespace”, maar:
- Plaats alle bronberichten in een JSON-bestand in de Data namespace op Commons in het “banana” formaat, zoals in MediaWiki extensies, met qqq voor documentatie.
- (Er moet een beslissing worden genomen of de gegevens van alle talen in een JSON structuur worden gezet, of een slot per taal.)
- Het JSON-bestand is als een MCR-slot opgeslagen met de wiki pagina met de code van de module.
- Deze syntaxis kan ook worden gebruikt voor core en extensie teksten.
- Voeg aan de extensie Translate toe het laden van de bronberichten en het schrijven van de vertalingen per taal naar JSON-bestanden.
- Voeg Lua functies toe aan de standaard Scribunto bibliotheek om de berichten te laden.
- Gebruik een ander JSON-bestand voor het organiseren van de vertaalbare bestand voor het in Translate gebruikersvriendelijker tonen van de selectie van de berichtengroep.
Voordelen
- Wordt elegant opgeslagen met de module.
- Als de module globaal wordt dan worden de gegevens ook globaal.
- Er kunnen bij het aanmaken van MCR-slots wat rechten benodigd zijn, maar dat is geen probleem omdat het aanmaken van nieuwe berichtenbestanden niet iets is wat aan nieuwkomers zal worden overgelaten. Het bewerken is voor de meeste bewerkers benaderbaar.
Nadelen
- Er is wat ontwikkeling nodig on het aanmaken van slots te gaan ondersteunen.
- Een nieuw FFS in Translate moet worden ontwikkeld en onderhouden. Wij hebben en nieuw type MessageGroup nodig zowel als voor MessageLoading.
- In de tijd van globale modules en sjablonen is het onduidelijk hoe het lokaal wordt aangepast op de wiki's.
- Een gebruikelijk nadeel van de MCR-slot aanpak: vermenging van rechten en geschiedenis. Het programmeren van code heeft hetzelfde beveiligingsniveau als vertalingen, elke vertaler heeft dus het recht om de effectieve code aan te passen. Bij de globale programmering is er geen geschiedenis van effectieve wijziging, dit wordt ondergesneeuwd tussen de bewerkingen vanwege het vertalen. Als de beveiliging en de geschiedenis wordt gescheiden, dan zijn dat individuele pagina's maar geen MCR.
TemplateData
Beschrijving
Gelijkwaardig aan de bovenstaande JSON-voorstellen, maar met de JSON binnen TemplateData opgeslagen:
- Slaat alle bronteksten als een JSON-waarde op in TemplateData geassocieerd met een sjabloon die de module gebruikt. Behalve dat het een onderdeel is van een grotere JSON structuur is het formaat gelijk aan het formaat “banana”, zoals bij MediaWiki extensies, inclusief qqq voor documentatie.
- Deze syntaxis kan ook worden gebruikt voor core en extensie teksten.
- Voeg aan de extensie Translate toe het laden van de bronberichten en het schrijven van de vertalingen per taal naar JSON-bestanden.
- Voeg Lua functies toe aan de standaard Scribunto bibliotheek om TemplateData en de berichten te laden.
- Gebruik een ander JSON-bestand voor het organiseren van de vertaalbare bestand voor het in Translate gebruikersvriendelijker tonen van de selectie van de berichtengroep.
Voordelen
- Doorgaan met bestaande TemplateData technologie.
- TemplateData kent al wat ondersteuning voor internationalisatie, bijvoorbeeld sjabloonbeschrijving in meerdere talen.
- De 'keys' kunnen via de TemplateData editor worden beheerd (daar is wel een wijziging van de UI van de editor voor nodig).
- De technologie kan later worden gedeeld met de sjablonen.
- Als TemplateData later naar MCR zou worden verplaatst (taak T56140), dan wordt het daar naar verplaatst.
Nadelen
- There is a hard-coded limit of 64 KiB (gzipped) in the TemplateData extension’s code. While this is enough room for something like 700 messages, we have about 400 languages to manage. When using the rate at which MediaWiki core messages are localized, there is room for only 20 messages.
- Hiervoor moet ondersteuning voor TemplateData worden toegevoegd aan Scribunto (taak T107119).
- Er moet ondersteuning voor een nieuw bestandsformaat (FFS) worden ontwikkelt en onderhouden in de extensie Translate.
- In de tijd van globale modules en sjablonen is het onduidelijk hoe het lokaal wordt aangepast op de wiki's.
Berichten als pagina's in de MediaWiki space
Beschrijving
- Sla de vertaalbare berichten op in de MediaWiki namespace, net zoals bij de berichten in de core en de extensies.
- Maak voor Translate berichtengroepen aan met een JSON of YAML bestand dat als wiki-pagina wordt opgeslagen. Dit wordt al ondersteund (WikiMessageGroup) met spatie gescheiden lijsten, er is echter geen mechanisme bekend om groepen te definiëren in de wiki zelf.
Voordelen
- Dat is de meest natuurlijke manier om in Translate te werken (er moet hiervoor waarschijnlijk een 'organizer' van de berichtengroepen worden ontwikkeld).
- In Scribunto zijn er al parserfuncties voor het laden van procesberichten.
- Kan op lokale wiki's worden aangepast wanneer de modules globaal worden op dezelfde manier dat dat gedaan wordt voor de berichten van de core en de extensies.
Nadelen
- Dubbele functie van berichtenlijsten als ook het ze gescheiden aanmaken.
- Voor het aanmaken van berichten zijn beheerders of interface-bewerkersrechten nodig. Daardoor kunnen minder mensen zorgen voor een uitgebreidere ontwikkeling van modules en het oplossen van fouten.
- Gebrek aan fysieke eenheid. Veel gedistribueerde ontwikkelteams maken en onderhouden packages van modules, globale sjablone, samen met TemplateData of JavaScript gadget, maar dat zou geen naamconflicten moeten geven tussen packages met vergelijkbare doelen. Moet per package worden gebundeld.
Lua table
Description
Do it similarly to existing solutions in Module:I18n on Commons and Module:Wikidades/i18n on the Catalan Wikipedia, but:
- Standaardiseer het Lua tabelformaat: Beslis of een key van een bericht naar veel vertalingen verwijst met een index per taal of dat taalcodes verwijzen naar veel van die keys, enz.
- Voeg functies toe aan de standaard Scribunto bibliotheek om de berichten te laden.
- Voeg ondersteuning toe voor het lezen en schrijven van dit bestandsformaat naar Translate.
Voordelen
- Normaal in Lua.
- Continuïteit met wat bestaande oplossingen.
Nadelen
- Dit is bestaande code, maar foutgevoelig en minder veilig. (Wij hebben al berichten in PHP arrays gebruikt, dat hebben wij afgebouwd.)
- Het is gewoon in Lua, maar wat als Scribunto ondersteuning nodig heeft voor andere programmeertalen? Er zijn herhaaldelijk verzoeken om o.a. JavaScript, Python en Rexx te ondersteunen.
- Taalcodes met een koppelteken moeten met vierkante haken geschreven worden, dat ligt niet voor de hand en is foutgevoelig.
Tabel met voorgestelde oplossingen
| Functie | Vertaalbare pagina | JSON tab-bestand in de Data namespace op Commons | JSON-bestand in een MCR-slot | TemplateData | Berichten MediaWiki space | Lua tabel |
|---|---|---|---|---|---|---|
| Wijzigingen vertalen (details: “Engineering overwegingen”) | klein | groot | groot | groot | klein | groot |
| Er is het recht nodig om bronberichten te bewerken | Voor vertalen markeren | Nee | Slots aanmaken | Nee | Ja - beheerder of interface bewerken | Nee |
| FFS vertalen | Geen | Groot | Groot | Groot | Geen | Groot |
| On-wiki aanpassen | Onduidelijk | Onduidelijk | Onduidelijk | Onduidelijk | Waarschijnlijk gemakkelijk, maar er kunnen performance problemen zijn | Onduidelijk |
| Gelijkwaardig als bij core en extensies | Nee | Komt erg overeen | Komt erg overeen | Komt veel overeen | Ja, maar alleen voor onwiki editoren | Nee |
| Leesbare keys van berichten | Teer, moet aangepast worden in Translate | Ja | Ja | Ja | Ja | Ja |
| Importeren en exporteren | Niet eenvoudig | Niet eenvoudig | Eenvoudig | Eenvoudig | Niet eenvoudig | Waarschijnlijk eenvoudig |
| Kan ook gebruikt worden in sjablonen op dezelfde wiki | Direct | Via een module | Via een module | Via een module | Direct | Via een module |
| Onduidelijkheden afhandelen | Waarschijnlijk al gedaan | Niet triviaal werk nodig | Niet triviaal werk nodig | Niet triviaal werk nodig | Waarschijnlijk al gedaan | Niet triviaal werk nodig |