Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aggiungere gestione multilingua #41

Open
nazarenomanco opened this issue Mar 7, 2016 · 11 comments
Open

Aggiungere gestione multilingua #41

nazarenomanco opened this issue Mar 7, 2016 · 11 comments

Comments

@nazarenomanco
Copy link
Contributor

Usiamo WPFLocalizeExtension?
Inseriamo dal subito per non dover ripassare tutto il sorgente?

@mauroservienti
Copy link
Member

Quale è il vantaggio di usare quello rispetto al normalissimo binding con un ResourceDictionary?

@nazarenomanco
Copy link
Contributor Author

Per quello che ci serve ora forse nessuno ma è un prodotto maturo che nelle mie precedenti esperienze di applicazioni multilingue fa il suo lavoro bene e in modo poco invasivo.

https://wpflocalizeextension.codeplex.com/

Giusto per non partire con un ResourceDictionary e poi accogerci di aver bisogno di qualcosa di più.

@mauroservienti
Copy link
Member

Vendimi che cosa fa in più rispetto ad un Resx, non voglio fare il polemico voglio solo capire quali sono i vantaggi rispetto a gestire con Resx e DataBinding.

@nazarenomanco
Copy link
Contributor Author

@mauroservienti se per quanto riguarda le labels possiamo procedere con i Resx (che in futuro, se serve ci daranno possibilità di usare tools di traduzione pro), come facciamo con i valori contenuti sul DB (ad esempio la descrizione del trattamento)?

Switch a caldo o restart?

@mauroservienti
Copy link
Member

@mauroservienti se per quanto riguarda le labels possiamo procedere con i Resx (che in futuro, se serve ci daranno possibilità di usare tools di traduzione pro), come facciamo con i valori contenuti sul DB (ad esempio la descrizione del trattamento)?

Usiamo la descrizione del trattamento come esempio, mi stai dicendo che:

  • la descrizione è un valore imputato dall'utente, in fase di configurazione o in fase operativa poco importa
  • nella stessa installazione ci sono utenti che vogliono vedere il valore di cui sopra in lingue diverse

Giusto?

Switch a caldo o restart?

se usiamo i ResX con data binding per la UI lo switch a caldo è compreso nel prezzo 😄

@nazarenomanco
Copy link
Contributor Author

Si corretto... Pensavo a una soluzione traduzione su DB... Ma se troviamo come renderla uniforme tanto meglio.
Soluzione attuale : una tabella aggiuntiva con le traduzioni nelle varie lingue supportate

@mauroservienti
Copy link
Member

ma è un macello, significa che in fase di inserimento di un valore devi inserire tutte le lingue giusto? Ergo sto editando la descrizione del trattamento, le lingue supportate sono 4, devo farti vedere 4 Textbox. Giusto?

Non solo ammazza anche le performance, perché ogni query diventa una join.

  • Ma di quanti tipi di valori/quanti valori stiamo parlando? Cioè se le lingue supportate sono 4 e devo inserire note per un processo di estrusione devo farlo in 4 lingue?
  • Sono solo valori di configurazione? o anche altro?

@nazarenomanco
Copy link
Contributor Author

Ci sono "le label" e quelle le facciamo con i ResX

Descrizione delle anagrafiche in lingua. In questo caso, al momento, la soluzione usata da altre parti è una sorta di left outer join un una tabella con le traduzioni (se non ci sono fallback su standard = inglese).

Per rendere la cosa meno "left outer" siamo passati a copiare l'inglese sulla nuova lingua e poi se lo sistemano (da configurazione delle anagrafiche).

Le anagrafiche non sono molte... ma servono in varie parti della applicazione (il trattemento viene abbinato alle bobine ad esempio)

Sono comunque tutte "tabelle" la cui necessità di traduzione è conosciuta a priori, ma il numero di righe (ad esempio il numero e la codifica dei trattamenti) è decisa dall'utente.

@mauroservienti
Copy link
Member

e se cambiano cambiano solo cambiando la configurazione, che presumo non essere un'operazione che succede tutti i giorni. Nel qual caso potremmo cachare queste informazioni sul client. Giusto?

@nazarenomanco
Copy link
Contributor Author

nazarenomanco commented Jun 6, 2017 via email

@mauroservienti
Copy link
Member

Avendo un socket SignalR aperto con i client, mandare un messaggio per invalidare la cache locale è banale.

@mauroservienti mauroservienti removed their assignment May 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants