Traduzione e correzioni testo

[giulio63]

Nella Tab "Telefonia" è indicato "acount" invece di "account" o "accounts"

Nella Tab "Estensioni"

• Il titolo è "Elenco epplicazioni" invece del corretto "Elenco applicazioni"
• in Aria2 GUI, App elenco non autorizzati, Applicazione XUPnP,

correggere da "è non è installata" in "non è installata"

Tradurre la sezione relativa a Telstra GUI

[nclmrc]

UP-> connesso, down-> disconnesso

[nclmrc]

pure qua

[nclmrc]

piattaforme

[bovirus]

@nclmrc

Per "Up" non so se si può fare. Per "piattaforma" correggo nella prossima build.

[bovirus]

@FrancYescO

Nuova PR con proposte modifiche sorgente per traduzione "Up".

@nclmrc

Se trovi altre stringhe non tradotte tipo "Up" per favore segnalali e cerchiamo se possibile di sistemare anche quelli.

[Ghost9090]

@FrancYescO @Ansuel

[nclmrc]

@Ghost9090 non è un problema di traduzioni. Metti il canale stabile, aggiorna e poi rimetti sviluppatore.

[nclmrc]

[bovirus]

@FrancYescO

File www\docroot\diagnostic-modgui-modal.lp

In tutte le stringhe tipo

ngx.print(format('{ "state":"%s","log_msg":"%s" }',state,log))

per avere la traduzione la stringa

"state" non dovrebbe essere sostituita con T"state" state (come variabile nella formula) non dovrebbe ssere sostituita nella forma con T(state)

e avere quindi la riga come

ngx.print(format('{ T"state":"%s","log_msg":"%s" }',T(state),log))

Nei file

usr/lib/lua/web/content_helper.lua usr/lib/lua/web/post_helper.lua

sembra che manca la riga iniziale

gettext.textdomain('webui-core')

che abilita le la traduzione delle relative stringhe.

[nclmrc]

[nclmrc]

@Ansuel io questo issue l'ho lascerei aperto

[bovirus]

@nclmrc Grazie della segnalazioni. Fix nella prima build disponibile. Se trovi altri stati da tradurre per favore segnalalo.

[nclmrc]

[nclmrc]

[giulio63]

nella tab "Servizi WAN" riguardo la nuova funzionalità di poter gestire più servizi DDNS credo sia corretto rinominare sia fuori che dentro la tab, la scritta DynDns ( che è il nome di un servizio DDNS ) con il termine corrispondente al tipo di serivizio : DDNS

[nclmrc]

WoL

Info aggiornamento

[nclmrc]

UPnP

[nclmrc]

Port Forwarding

[kevdagoat]

I will fix this

Sent from my iPhone

On 25 Mar 2019, at 2:04 am, Niccolò Marchi notifications@github.com wrote:

Port Forwarding

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[nclmrc]

[bovirus]

@nclmrc

Aggiungo alle fix prossima build.

[nclmrc]

è doppione visto che questi sono i valori che dovrebbero apparire in modalità connessione in statistiche, sarebbe opportuno replicarli. penso vada sostuito ip fisso con ip statico in statistiche.

[nclmrc]

[nclmrc]

Andrebbe anche riaggiustata l'indentazione @FrancYescO e cercare di non far stare dentro l'ultima riga

[nclmrc]

@bovirus manca static route da tradurre

[bovirus]

@nclmrc

Va modificato il sorgente

_-- File www/card/015iproutes.lp format( N('<strong id="iproutescardnoofipv4staticroutes" %1$s>**%2$d IPv4 Static Route_', '<strong id="iproutescard_noofipv4staticroutes" %1$s>%2$d IPv4 Static Routes** ', ipv4_count),

** Aggiunta spazio

• File www/docroot/modals/speedservice-modals.lp

"Step Duration(ms):" -> "Step Duration(ms):"

- File webui.po

msgid "Step Duration(ms):" -> msgid "Step Duration (ms):"

** cambio Ghz in GHz

• File www/docroot/modals/contentsharing-modals.lp

  tinsert(html, ui_helper.createAlertBlock(T"It is recommended to use the USB in the 2.0 standard. The use of USB in 3.1 standard can remarkably affect the Wi-Fi performance at 2.4 Ghz band.", warning)) tinsert(html, ui_helper.createAlertBlock(T"It is recommended to use the USB in the 2.0 standard. The use of USB in 3.1 standard can remarkably affect the Wi-Fi performance at 2.4 GHz band.", warning))

• File webui-ciontensharing.po

msgid "It is recommended to use the USB in the 2.0 standard. The use of USB in 3.1 standard can remarkably affect the Wi-Fi performance at 2.4 Ghz band." msgid "It is recommended to use the USB in the 2.0 standard. The use of USB in 3.1 standard can remarkably affect the Wi-Fi performance at 2.4 GHz band."

@Ansuel @FrancYescO

Potete per favore pensare voi al sorgente? Grazie.

[nclmrc]

C'è da tradurre le ultime aggiunte di @Ansuel. Per esempio do not disturb ecc.

[bovirus]

@nclmrc

Gli sviluppatori sembra non abbiano intenzione di inserire le correzioni delle stringhe se non nella versione definitiva.

Io ho un'idea diversa sull'aggiornamento delle stringhe (io aggiornerei man mano che le stringhe appaiono nel sorgente), ma la decisione è loro e io la rispetto.

Per questo mi sono fermato nella revisione dell'interfaccia.

[nclmrc]

Ok, io intanto mi metto per l'avanti. Sono state fatte delle aggiunte anche nella scheda firewall.

[bovirus]

@nclmrc

Ho già tradotto tutte le stringhe. Ma non ho ancora fatto la PR. Appena sistemano le stringhe nel sorgente carico la PR.

[FrancYescO]

Modifiche al sorgente o ai .po che sia meglio tenere un unica PR aperta (che già c'è) con tutte le modifiche alle stringhe all'interno, inutile triggerare nuove build solo per piccoli cambi stringhe

[bovirus]

@FrancYescO

Fino ache non si fanno quelle modifiche al file sorgente alcune correzioni del file testo non sono visibili.

Capisco di non fare una build specifica ma nell'occasione di altre modifcihe più importanti si possono inserire anche quelle piccole modifiche richeiste al file sorgente (che sono dei refusi delle stringhe sorgenti).

L'importante è che quando viene proposta una modifica ai file .po delle traduzioni il merge sia per quanto possibile veloce per non rischiare di perdere il lavoro svolto nella tarduzione causa ulteriore modifica dei file .po sorgenti e difficoltà nella sincronizzazione delle stringhe stesse..

[FrancYescO]

No perche si confonderebbero modifiche alle stringhe tra altre modifiche importanti, al contrario tenere tutte le stringhe da modificare in un unico PR da unire alla fine mantiene tutto il blocco isolato

Risolvere i conflitti sui .po è l'ultimo dei problemi

---

From: bovirus notifications@github.com Sent: Tuesday, May 14, 2019 9:06:28 AM To: Ansuel/tch-nginx-gui Cc: Francesco M; Mention Subject: Re: [Ansuel/tch-nginx-gui] Traduzione e correzioni testo (#407)

@FrancYescOhttps://github.com/FrancYescO

Fino ache non si fanno quelle modifiche al file sorgente alcune correzioni del file testo non sono visibili.

Capisco di non fare una build specifica ma nell'occasione di altre modifcihe più importanti si possono inserire anche quelle piccole modifiche richeiste al file sorgente (che sono dei refusi delle stringhe sorgenti).

L'importante è che quando viene proposta una modifica ai file .po delle traduzioni il merge sia per quanto possibile veloce per non rischiare di perdere il lavoro svolto nella tarduzione causa ulteriore modifica dei file .po sorgenti e difficoltà nella sincronizzazione delle stringhe stesse..

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Ansuel/tch-nginx-gui/issues/407?email_source=notifications&email_token=ABC43ANDSGW5T5LRYTMT7BLPVJQHJA5CNFSM4GMIV3TKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVKPGFQ#issuecomment-492106518, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABC43APM2TICHMHF4WZS3ITPVJQHJANCNFSM4GMIV3TA.

[bovirus]

@FrancYescO

Secondo me in questo modo per vedere le traduzioni al loro posto se si aspetta il rilascio della build finale ci sono due incovenienti.

Gli utenti vedranno le traduzioni al loro posto solo nella build finale. A me personalmente questa soluzione non piace e mi piacerebbe vedere che la traduzione procedesse di pari passo con l'aggiunta delle nuove stringhe.

Il test della traduzione di può fare solo nella build finale e quindi ci vorranno ulteriori step per la revisione/modifica delle stringhe. Step che magari dovranno attendere la sucecssiva versione stable (tempi lunghi). Se invece la traduzione procede di pari passo in ogni fase successiva la traduzione può essere revisionata/affinata.

Secondo me fare tutte le modifiche della traduzione solo nella fase finale e non come si era fatto fino ad un pò di tempo fa mano mano che le stringhe venivano inserite a me non sembra la soluzione più efficace/lineare/professionale.

Personalmente vedere, anche se è una GUI in versione dev, parti in italiano e parti in inglese a me non piace perchè mi da l'idea di una cosa non realizzata a puntino.

Personalmente, per testare la traduzione, vista la situazione attuale, sono stato costretto attualmente a svilupparmi a parte, partendo dalla dev ogni volta rilasciata, una versione con le traduzioni tutte attive in modo da verificare in tempo reale se le traduzioni sono corrette nel contesto, se non ci sono problemi sulla lunghezza delle stringhe, etc.

Secondo me questo lavoro di test della traduzione è atrettanto importante dell'attenzione nel fix del codice sorgente.

Mi piacerebbe conoscere il parere degli utenti più attivi nella segnalazione dei problemi sulla traduzione al riguardo di questa situazione sulle traduzioni.

@nclmrc @Ghost9090 @giulio63

Voi che siete quelli più attivi nelle traduzioni che ne pensate?

[FrancYescO]

Certo che sarebbe meglio tutto contemporaneo ma che una volta che la traduzione e' stata fatta e revisionata (si puo' benissimo revisionare gia' dal PR) e' inutile tornarci sopra e si lascia nel PR da applicare

la versione DEV e' una cosa non realizzata a puntino perche' e' appunto in sviluppo, e trovarsi problemi generati da una traduzione cambiata mentre si sta sviluppando una funzione e' un grandissimo rompimento di scatole.

che non ci siano stringhe tradotte fino alla stable non e' un problema l'importante e' che ci siano nel PR da applicare e che le comprenda tutte in una volta senza star li a generare una build per ogni stringa da cambiare o formattazione da inserire.

Poi certo che se il PR inizia a diventare di notevoli dimensioni vale la pena integrarlo anche in dev ma ad ora il PR aperto non ha altro che un paio di spazi e maiuscole aggiunte, insomma roba davvero superflua che per me non motiva ancora un merge (che per quanto si sta tirando alla lunga questa discussione farei pure, ma il modo di lavorare non migliorerebbe quindi aspetto si capisca cosa voglio dire).

[Ghost9090]

io direi di controllare la gui dalla testa ai piedi e di tradurre la gui di botto così almeno non si aprono sempre delle PR per le traduzioni

[bovirus]

@Ghost9090

Che è la mia idea. GUI con le stringhe tradotte man mano che compaiono. Con la possibilità di segnalare solo gli errori/incongruenze.

[Ghost9090]

@bovirus in effetti è meglio così tradotta tutta quanta almeno dopo non ci sono problemi con la gui.

[nclmrc]

[nclmrc]

[giulio63]

nel tab "Impostazioni Eco" correggere da "auomatico" in "automatico"

[giulio63]

nel tab "pianificazione" correggere da "NoNDisturbare" in "NonDisturbare" ( non so se sia anche da separare le 2 parole con uno spazio sia fuori che dentro il tab

[bovirus]

Grazie delle segnalazioni. Inserita PR con correzioni. La stringa originale è "DontDisturrb" quinidi l'ho tradotta con "NonDisturbare".

[nclmrc]

[Ansuel]

@nclmrc scusate off puoi darmi qualche feedback su quel grafico ?

[bovirus]

@Ansuel

File _www\info_cards\004grphs.-lp (file traduzione webui-core.po)

' .. T("Polling every 10 seconds") .. '

quindi sembra che il sorgente sia OK. La stringa non c'è pero nel file webui-core.po (it e de).

Credo che il problema sia nel sistema automatico di generazione dei file .po in quanto è già capitato che se prima o dopo la stringa c'è ".." la rpocedura non crea la stringa nei file lingua.

[nclmrc]

@Ansuel mi sembra che funzioni bene perchè me lo chiedi?

[Ansuel]

ho fatto dei cambiamenti ora dovrebbe funzionare per bene...

[bovirus]

@Ansuel

Dubito possa funzionare in quanto sembra manchi la stringa nel file lingua.

[Ansuel]

in teoria si sarà solo qualche errore nella scansione del file?