In a json file, I have some fields that have a list of dictionaries with the locale and the translated text:
description_localized: [
{
locale: "en-UK",
value: "Read along"
},
{
locale: "de-DE",
value: "Lesen und"
},
{
locale: "fr-FR",
value: "Lis avec"
},
]
There are other fields where there are two keys in the value key:
path_localized: [
{
locale: "de-DE",
value: "{"identifier"=>"", "value"=>"http://path_6987.path"}"
},
{
locale: "es-ES",
value: "{"identifier"=>"", "value"=>"http://path_4685.path"}"
},
I already created a schema that grabs these fields, but instead of pulling the entire dictionary, on Graphql, I will need to be able to make a query where I only specify the language-locale I want (e.g. fr-FR) and that would only fetch the translated value for that one language (fr-FR). I don't want to get an array of all localized languages as this will be very taxing and will take longer to load per query.
Does anyone have any ideas on how I could accomplish this? Maybe through a resolver where I pass in the language as a parameter? But where would the languages be defined? I may need to clean this but we have an assortment of locale definitions: en_UK, en-UK, UK, en_UK_CO... Also, if the queried language is not found, how could I define a fallback?
Any guidance would be appreciated.
Thanks!
What stack are you working on, Node.js? If so, you can find a localization example here: https://github.com/kriasoft/nodejs-api-starter ..it uses "i18next" module to detect user's language, fallback to default language etc. then you can pass "lng" string as a context variable and use that inside of your "resolve()" methods. See src/app.js, src/Context.js.
Related
The log4j2 PatternLayout offers a %notEmpty conversion pattern that allows you to skip sections of the pattern that refer to empty variables.
Is there any way to do something similar for JsonTemplateLayout, specifically for thread context data (MDC)? It correctly (IMO) suppresses null fields, but it doesn't do the same with empty ones.
E.g., given the following in my JSON template:
"application": {
"name": { "key": "x-app", "$resolver": "mdc" },
"context": { "key": "x-app-context", "$resolver": "mdc" },
"instance": {
"name": { "key": "x-appinst", "$resolver": "mdc" },
"context": { "key": "x-appinst-context", "$resolver": "mdc" }
}
}
is there a way to prevent blocks like this from being logged, where the only data in the subtree is the empty string values for context?
"application":{"context":"","instance":{"context":""}}
(Yes, ideally I'd prevent those empty strings being put into the context in the first place, but this isn't my app, I'm just configuring it.)
JsonTemplateLayout author speaking here. Currently, JsonTemplateLayout doesn't support blank property exclusion for the following reasons:
The definition of empty/blank is ambiguous. One might have, null, {}, "\s*", [], [[]], [{}], etc. as valid JSON values. Which one of these are empty/blank? Let's assume we have agreed on a certain behavior. Will it apply to the rest of its users?
Checking if a value is empty/blank incurs an extra runtime cost.
Most of the time you don't care. You persist logs in a storage system, e.g., ELK stack, and there blank value elimination is provided out of the box by the storage engine in the most efficient way.
Would you mind sharing your use case, please? Why do you want to prevent the emission of "context": "" properties? If you deliver your logs to Elasticsearch, there you can easily exclude such fields via appropriate index mappings.
Near as I can tell, no. I would suggest you create a Jira issue to get that addressed.
I have a list of elements (OData set) and use a binding to show this list.
One field is for a quantity value and this value could sometimes need some decimal places.
The requirement is: only show that amount of decimal numbers that is also available in the OData service.
Annotation techniques can't be used.
I 'hacked' something that is misusing a formatter to update the type of a binding. But this is 'a hack' and it is not possible to convert it to XML views. (The reason is a different handling of the scope the formatter will be called).
So I am searching for a working solution for XML views.
The following code would not work but shows the issue:
new sap.m.Input({ // looking for an XML solution with bindings
value: {
path: "Quantity",
type: new sap.ui.model.type.Float({
// formatOptions
maxFractionDigits: "{QuantityDecimals}",
// ...
}, {
// constraints
minimum: 0
}),
// ...
}
});
The maxFractionDigits : "{QuantityDecimals}" should be "dynamic" and not a constant value.
Setting formatOptions and constraints dynamically in XML (via bindings or a declared function) is unfortunately not (yet) supported. But IMHO this is a valid enhancement request that app developers would greatly benefit from, since it encourages declarative programming.
I already asked for the same feature some years ago but in a comment at https://github.com/SAP/openui5/issues/2449#issuecomment-474304965 (See my answer to Frank's question "If XMLViews would allow a way to specify the dynamic constraints as well (e.g. enhanced syntax), would that fix the problem?").
Please create a new issue via https://github.com/SAP/openui5/issues/new with a clear description of what kind of problems the feature would resolve and possibly other use cases (You can add a link to my comment). I'll add my 👍 to your GitHub issue, and hopefully others too.
I'll update this answer as soon as the feature is available.
Get your dynamic number from your model and store it in a JS variable.
var nQuantityDecimals = this.getModel().getProperty("/QuantityDecimals");
new sap.m.Input({
value : {
path : "Quantity",
type : new sap.ui.model.type.Float({
maxFractionDigits : nQuantityDecimals,
source : {
groupingSeparator: ",",
decimalSeparator: ".",
groupingEnabled: false
}
}, {
minimum:0
})
}
}),
The data I store is at the moment written in english. So I plan to make this content localized/translatable and would like to give this option to users.
Here are my user stories:
(1) As a user I want to select the preferred language of my content (e.g. german). If the text is not available in german, please give me the content in the fallback language (e.g. english).
(2) As a user I want to be able to translate a given model.
Given the following:
1) A model, e.g. Message with two properties: title and description. It can be expected these two properties are in english (by default).
2) A command, e.g. translateMessage which will receive a payload with: title, description and locale.
What's an accepted way to handle localization of those models?
A solution I come up with:
Let's say our Message will have the following properties (in Typescript):
{
title: string;
description: string;
}
I would extend it with a translations object. Where each key in there is a locale and has an object with translated strings.
{
title: string;
description: string;
translations: {
[key: string]: {
title: string;
description: string;
}
}
}
The readModel will be the same as above and it is up to the client to decide which strings to display.
The command translateMessage will receive the payload as described above and publish an event with that. The readModel will react to that event in a way, that it pushes the new payload data onto the translations object in that model.
For model creation, if the data is received in a different locale than the default one, then the event handler will put those translated strings prefix with the locale they were written in, into the root, e.g. model.title can be something like [de] Nachrichtentitel. The model would look like this:
{
title: '[de] Nachrichtentitel'
description: '[de] Nachrichteninhalt'
translations: {
de: {
title: 'Nachrichtentitel'
description: 'Nachrichteninhalt'
}
}
}
You see any problems with that? Are there other already established best-practices on how to do that?
Is there any way to specify the language that we need to extract from an image.
for example: I have an image that contains arabic+ french characters and the API returns a mixed text , is there a way to extract only french characters
You can use languageHints inside an imageContext request seting it to 'fr' for example:
"requests": [
{
"imageContext": {
"languageHints": [
"fr"
]
You can test it here
I have two methods i'm trying to write using globalize. One to format Numbers and one to format Currency.
function currencyFormatter(value, locale, fieldDefinition) {
var formatter = Globalize('en').currencyFormatter( 'INR' )
return formatter( value )
}
function numberFormatter(value, locale, fieldDefinition){
var formatter = Globalize('en').numberFormatter()
return formatter( value )
}
When I use the 'en' locale with 'INR' currency code for currencyFormatter or 'en' for numberFormatter i'm expecting to see something like ₹12,34,567.89 however what i get in both cases is something like ₹1,234,567.89 (minus currency symbol for number). I looked inside my node_modules folder cldr-data/main/en-IN/numbers.json and found this:
"percentFormats-numberSystem-latn": {
"standard": "#,##,##0%"
},
"currencyFormats-numberSystem-latn": {
"currencySpacing": {
"beforeCurrency": {
"currencyMatch": "[:^S:]",
"surroundingMatch": "[:digit:]",
"insertBetween": " "
},
"afterCurrency": {
"currencyMatch": "[:^S:]",
"surroundingMatch": "[:digit:]",
"insertBetween": " "
}
},
"standard": "¤ #,##,##0.00",
"accounting": "¤#,##0.00;(¤#,##0.00)",
I also went to CLDR website and dug up what i believe is the format file (en-IN.xml) and found this:
<rulesetGrouping type="OrdinalRules">
<ruleset type="digits-ordinal">
<rbnfrule value="-x">−→→;</rbnfrule>
<rbnfrule value="0">=#,##0=$(ordinal,one{st}two{nd}few{rd}other{th})$;</rbnfrule>
</ruleset>
</rulesetGrouping>
Both of these support the results we are getting are correct and our assumptions on what we expect are wrong. However, if you look out on the internet there are many reputable sites that say our assumptions are correct and the results are incorrect.
This leaves me in a state of not knowing what to do. Who's right? Can you help us to answer this question?
Also, is there a way to "overwrite" the default format if for whatever reason we wanted to change it?
You should use en-IN for English as spoken in India, i.e., Globalize('en-IN').