Il tuo requisito:
Affinché il mio sito funzioni in più lingue
come utente autenticato,
devo essere in grado di tradurre immediatamente tutte le chiamate di traduzione trovate nella base di codice del mio sito che sono state eseguite con la funzione t ().
La descrizione di tale requisito è persino vicina a ciò che stai chiedendo?
Crawlers
Come qualcuno ha detto, un crawler potrebbe teoricamente passare attraverso l'intero sito per forzare la registrazione di tutte le chiamate t (). Ma 1) il crawler non sa quali pagine eseguire la scansione; 2) non stiamo cercando di mantenere un elenco di pagine da scansionare, quindi; 3) non vogliamo usare un cingolato, punto. Eww. Solo, eww. Giusto?
Il problema
- Non abbiamo un elenco di tutte le stringhe di traduzione.
- Drupal / PHP è un linguaggio dinamico a differenza di C che viene compilato. Quindi non possiamo andare ad esempio: compilare l'intera base di codice, quindi trovarmi tutte le istanze di questa funzione
t(), quindi registrare quelle istanze nel database, quindi tradurre tutte quelle istanze registrate t()in una volta sola. Non credo sia un'opzione che abbiamo sul nostro tavolo.
- Uno strumento di analisi del codice statico sarebbe impotente per lo stesso motivo per cui un crawler sarebbe impotente. Ho trovato questo
t()in questo file. Grande! In quale URL è utilizzato? Qual è il contesto?
Attaccare il problema con gli strumenti attuali (Drupal e alcuni moduli contrib) e con i vincoli attuali (basandosi su chiamate a tema in tempo reale -> file modello -> t()chiamate), qui sembra un vicolo senza uscita. Potremmo aver bisogno di pensare un po 'fuori dagli schemi.
Ciò che ci serve
- Abbiamo bisogno di una fonte di dati, un modello, che mi dica quali stringhe di traduzione correnti abbiamo e qual è il loro contesto -
- Modello di dati proattivo. Il modello di dati corrente è reattivo (il modello viene aggiornato ogni volta che si verifica una chiamata
t()). Abbiamo bisogno di un modello di dati proattivo, uno in cui l'applicazione si occupa di cercare le t()istanze prima che vengano effettivamente eseguite dal cliente.
- Abbiamo bisogno del contesto.
t()da solo non lo taglia - perché - non sappiamo che stiamo traducendo "pippo", ma la lingua di destinazione che stiamo traducendo dipende dall'URL del luogo in cui si t()verifica. Anche se potessimo codificare la lingua di destinazione nella t()chiamata, ad esempio, utilizzando una chiamata wrapper, non funzionerebbe per i tuoi scopi.
Ho identificato alcuni degli strumenti che, se li avessimo, aiuterebbero il nostro problema. Con questi strumenti potremmo entrare nel modello di dati e dire: dammi tutte le stringhe racchiuse t()che non sono state ancora popolate. Ora inserisci queste traduzioni. Grazie.
E la prossima volta che arriva il cliente, le traduzioni sono lì sul posto.
Come potremmo ... costruire questi strumenti?
vincoli
- La lingua di destinazione non può essere sul modello, che è deciso dall'URL. Supponendo che la stringa debba supportare qualsiasi lingua.
- La stringa tradotta non può essere sul modello. La traduzione risiederà in un database.
Ora che ho riflettuto maggiormente sul problema e ho identificato alcune sfide e vincoli, posso pensare a qualsiasi soluzione disponibile là fuori o a creare soluzioni personalizzate.
Brainstorming della soluzione
Ho bisogno di qualcosa che lega "tutto" insieme. Che dire di ... un'entità?
- Un'entità può contenere il prodotto che deve essere tradotto.
- Le entità possono fornire la relazione - la colla - tra il prodotto che deve essere tradotto e il suo contesto.
- L'entità può specificare dire, in un campo, la posizione URL predefinita del prodotto.
- I token possono essere utilizzati per specificare posizioni alternative (lingue?) Su cui verrà visualizzato il prodotto.
- Le entità ci forniscono il modello di dati proattivo di cui abbiamo bisogno e il suo contesto. Il che a sua volta ci permette di fare cose come: andare nel database, prendere tutte le entità del prodotto e se non hanno una stringa di traduzione per i campi X, Y e Z, creare quelle stringhe di traduzione.
Quando il cliente quindi afferra /pl/product/200, fai un viaggio nel db, cerca il prodotto 200 e prendi la pltraduzione già esistente . Hai un campo titolo e didascalia anche per quel prodotto? Le traduzioni dovrebbero essere presenti anche lì.
Nota che qui sono molto vago e generico in termini di modulo di traduzione che stai utilizzando. Potresti benissimo finire con il tuo modulo di traduzione, molto probabilmente è così. Tutti i modelli di traduzione che ho visto in Drupal finora (a partire da D7, non ho ancora visto D8) sono reattivi, non proattivi.
In poche parole
In teoria, ci sono gli strumenti per costruire ciò di cui hai bisogno, le entità sono il componente chiave che legherebbe tutto insieme: - dati (stringa di traduzione), - lingue di destinazione. Non devi essere sull'entità stessa, preferibilmente un vocabolario tassonomico, diciamo per le lingue dei prodotti. o forse una tassonomia generica anche per altre entità. - Contesto. L'URL su cui viene visualizzata l'entità. L'URL conterrebbe un token e il token a sua volta farebbe riferimento alla tassonomia della lingua di destinazione.
Con questi tre ingredienti puoi dire: prendi tutte le productentità, vai sul URL aliascampo, ottieni il token di tassonomia, fai scorrere tutte le combinazioni di termini possibili, presenta tutte le combinazioni all'utente corrente usando una brutta forma molto grande - o, AJAX - e moduli multi-step (qualcosa del genere) e poiché l'utente attualmente connesso traduce le varie lingue per il prodotto 200, salvarle da qualche parte nel database
Da qualche parte nel database potrebbe esserci un campo API di campo nell'entità, il campo delle impostazioni appartenente a ciascuna entità (non esattamente l'API di campo, ma può ancora contenere dati) o una tabella separata che usi per questo. Penso che il salvataggio dei dati nell'entità manterrà il codice e i dati più ordinati e più facili.
Costruendolo: possibili soluzioni
- D8MI (Drupal 8 Multilingual Initiative)
- Codice personalizzato: traduzioni "indicizzate" rese disponibili nei modelli da t () interrogando e rendendo programmaticamente pacchetti disponibili e le relative implementazioni di hook a tema.
pseudocodice
Foreach entity (di tipo x),
Trova tutte le lingue (tassonomia o linguaggio principale associato al prodotto),
Rendering dell'entità,
- per rilevare le stringhe di traduzione t ()
- rendering chiamate theme (), che gestisce il livello di presentazione multilingue di il prodotto, non il modello di dati del prodotto stesso.
Risultato:
- La prima chiamata per il rendering del modello di entità in ogni lingua restituisce l'implementazione della lingua predefinita per ogni chiamata.
- I parametri t () sul modello sono ora memorizzati nella cache in Drupal e pronti per la traduzione (per ogni istanza di lingua, non per ogni istanza di prodotto).
- L'utente con ruolo di "traduttore" ora può accedere all'interfaccia di traduzione e tradurre tutti i parametri t () disponibili, per ciascuna lingua.
- Il proprietario del sito non ha bisogno di attendere che i clienti visitino ciascuna pagina del prodotto o visitino manualmente ogni pagina del prodotto, poiché ciò è stato programmato per lui.
Domande aperte:
- Qual è il contesto? Se eseguo una chiamata programmatica a theme () per ciascun pacchetto di entità "prodotto", registra la posizione da cui è stata effettuata la chiamata? Registra l'URL del nodo? Il "contesto" può essere modificato? Dove viene registrato il contesto? Cosa succede quando si dispone di modelli "dinamici", ovvero quando si dispone di più di un modello per prodotto e come si rilevano tali variazioni?
Come sempre, la teoria e lo pseudocodice sono utili solo per il brainstorming. Ma in fase di sviluppo difficilmente sapremo a che cosa siamo veramente confrontati fino a quando non inizieremo la prototipazione. Quindi, dopo aver elaborato un paio di vincoli, possibili soluzioni e possibili problemi o domande, ora posso procedere all'implementazione di una prova di concetto o di un prototipo funzionante. Ad alcune delle domande aperte sopra è possibile rispondere solo in questo modo, e la prima che prototipiamo (indipendentemente dal successo o dal fallimento), possiamo iniziare a rispondere ad alcune di queste domande o cambiare completamente l'approccio. Resta sintonizzato ~
wgeto altro. Hackish, ma hai detto che era permesso (: