Continuo a riscontrare un requisito i18n in cui i miei dati (non la mia interfaccia utente) devono essere internazionalizzati.Internazionalizzazione del contenuto in Entity Framework
public class FooEntity
{
public long Id { get; set; }
public string Code { get; set; } // Some values might not need i18n
public string Name { get; set } // but e.g. this needs internationalized
public string Description { get; set; } // and this too
}
Quali sono alcuni approcci che potrei utilizzare?
alcune cose che ho provato: -
1) memorizzare una chiave di risorsa nel db
public class FooEntity
{
...
public string NameKey { get; set; }
public string DescriptionKey { get; set; }
}
- Pro: Non c'è bisogno di query complesse per ottenere un tradotta entità.
System.Globalizationgestisce i fallback per te. - Contro: Le traduzioni non possono essere facilmente gestite da un utente amministratore (è necessario distribuire i file di risorse ogni volta che il mio cambio s).
2) Utilizzare un tipo LocalizableString un'entità
public class FooEntity
{
...
public int NameId { get; set; }
public virtual LocalizableString Name { get; set; }
public int NameId { get; set; }
public virtual LocalizableString Description { get; set; }
}
public class LocalizableString
{
public int Id { get; set; }
public ICollection<LocalizedString> LocalizedStrings { get; set; }
}
public class LocalizedString
{
public int Id { get; set; }
public int ParentId { get; set; }
public virtual LocalizableString Parent { get; set; }
public int LanguageId { get; set; }
public virtual Language Language { get; set; }
public string Value { get; set; }
}
public class Language
{
public int Id { get; set; }
public string Name { get; set; }
public string CultureCode { get; set; }
}
- Pro: Tutte le stringhe localizzate nella stessa tabella. La convalida può essere eseguita per stringa.
- Contro: le query sono orribili. Devono. Includere la tabella LocalizedStrings una volta per ogni stringa localizzabile sull'entità padre. I fallback sono difficili e richiedono un'estesa adesione. Non ho trovato un modo per evitare N + 1 durante il recupero ad es. dati per una tabella.
3) Utilizzare un'entità padre con tutte le proprietà invarianti e entità figlio che contengono tutte le proprietà localizzate
public class FooEntity
{
...
public ICollection<FooTranslation> Translations { get; set; }
}
public class FooTranslation
{
public long Id { get; set; }
public int ParentId { get; set; }
public virtual FooEntity Parent { get; set; }
public int LanguageId { get; set; }
public virtual Language Language { get; set; }
public string Name { get; set }
public string Description { get; set; }
}
public class Language
{
public int Id { get; set; }
public string Name { get; set; }
public string CultureCode { get; set; }
}
- Pro: Non è così difficile (ma ancora troppo duro) per ottenere! una traduzione completa di un'entità in memoria.
- Contro: Raddoppia il numero di entità. Non è possibile gestire le traduzioni parziali di un'entità, in particolare nel caso in cui, ad esempio, il nome provenga da
esma la descrizione provenga daes-AR.
ho tre requisiti per una soluzione
gli utenti possono modificare le entità, lingue e traduzioni in fase di esecuzione
Gli utenti in grado di fornire traduzioni parziali con le stringhe mancanti provenienti da un ripiego come da System.Globalization
Le entità possono essere messe in memoria senza eseguire in ad es. N + 1 problemi
Ancora non ho risposto, ero interessato anche io. – polkduran
Non è chiaro quale considerereste una risposta accettabile. Se qualcuno ha un'opzione 4 è probabile che abbia anche pro/contro. – explunit
Domanda chiarita. Non mi aspetto che ci sia una soluzione perfetta, ma spero ce ne sia uno migliore di quello che ho inventato finora. –