I’m currently working on exposing display ready fields that include localization, eventually to split all localized fields and logic out into a dedicated subgraph.
At it’s core, the localized fields are simple strings, but I’m considering adding a LocalizedString scalar to be more explicit about what the consumer should expect. It’s not a data point, it’s a localized and display ready value. However, the scalar itself isn’t going to be doing any serializing or parsing of the value… that will be relegated to the resolvers.
Here is an example:
type Genre {
name: String # data point or enum value like COMEDY, HORROR, etc
l10n: LocalizedString # localized display ready field like Comedy (en-US), Comedia (es-US), etc.
}
Currency, when combining multiple data points to make a display value, may be a better example.
type AmountDue {
value: Float
currency: String # data point or enum value like USD, EUR,
l10n: LocalizedString # like 'USD $10,000.50' for US USD, '10 000,50 €' for French EUR, '₹10,000.50' for Indian INR, etc.
}
These are contrived examples, but there are more relevant examples of combining data points to make a display ready value, then applying localization, in my real use cases.
But, the underlying question is, should I create a LocalizedString
scalar and comment blocks as a calling card to the underlying logic or just use the default String
scalar with comment blocks?