I am having a problem with how to use the entity type correctly in multilingual Agents.
If I were to make an entity type in a language let's say in THAI and a route for that specific entity using the $session.params.(entitytype) = something but then if my agent is multilingual then when I go to the same entity type in another language let's say English all the entity in my default language does not show up on the English agent. Do I just add all the English matching words to the Thai entity type? Or is it better the build 1 agent for each language? Or do I route to the samepage using a new $session.params.(entitytype) = english something and so one for each lang
Defult Thai Agent
Same Agent but English
Switching agents Is one approach, but if you want to use multilingual entities, yes, you should add all the matching words to the Thai entity type. For dialog flow, each language entity is separated from the in my experience, also you need to add both languages at the agent. some simpler entities can be handled by the agent that way.
Here is more info about it: https://cloud.google.com/dialogflow/es/docs/agents-multilingual
Entity entries are language-specific data.
First, you need to add entity entries to the entity type for each language. Then you can create multiple routes with conditions like $session.params.<entity_type_name> = "<some_text_in_Thai>" and $session.params.<entity_type_name> = "<some_text_in_English>".
Related
I have two websites and code base is same.
SiteA
SiteB
apps/company/components
How to pick different resource bundle translations for SiteA, SiteB in i18n ?
Thanks,
Sri
Can you please be specific, is this for server side translations or client side translations? For client-side translations, I had an issue with OTB ResourceBundleExportServlet detailed here.
sling:basename way:
Add a property sling:basename to mix:language node. Say sling:basename="siteA"
Pass the basename during bundle lookup. request.getResourceBundle("siteA", locale);
This will return keys from the specific basename only.
Client-side custom bundle exporter:
Keep separate dictionaries for SiteA and SiteB. For example: /apps/company/sitea/i18n, /apps/company/siteb/i18n.
If splitting dictionary is not possible, keep a nomenclature in your labels to identify site. For example all labels should be prefixed with siteA/siteA. Like siteA.clickhere, siteB.clickhere
Create custom servlet similar to ResourceBundleExportServlet. Keep the path as /libs/company/i18n/dict.
The custom servlet will check siteA or siteB from slingrequest and return respective labels only. Filtering the labels based of dictionary path(step 1) or prefix(step 2)
Create overlay to /libs/clientlibs/granite/utils/source/I18n.js. Change the urlPrefix to
var urlPrefix = "/libs/company/i18n/dict.";
Now the client side i18n lookup will pull entries from the custom exporter rather than OTB exporter
Server-side Resolver:
To differentiate sitea or siteb labels we need step 1 or 2 from above.
Once we know to identify site specific labels, we need only a helper util that checks site from request and resolves from specific dictionary or prefix
Hope this helps.
I've got a scenario where I have the following type of data that I want to specify in my properties file.
To describe it I have a domain, each which can have a type and subtype.
wallet.items.domain=APPLE,DOMAIN_TWO
wallet.domain.types.apple=TYPE_ONE, PAYPAL
wallet.domain.subtypes.apple=SUB_TYPE_ONE
wallet.domain.types.paypal=TYPE_ONE, TYPE_TWO, TYPE_THREE
wallet.domain.subtypes.paypal=SUB_TYPE_ONE, SUB_TYPE_TWO, SUB_TYPE_THREE, SUB_TYPE_FOUR
I want to validate that the types and the subtypes for a domain are valid in a generic manner. For example these are valid combinations.
APPLE, TYPE_ONE, SUB_TYPE_ONE
APPLE, TYPE_TWO, SUB_TYPE_ONE
APPLE, TYPE_TWO, SUB_TYPE_ONE
PAYPAL,TYPE_ONE,SUB_TYPE_ONE
My first challenge is to structure this in a properties file such that I can use them in a validate routine in groovy generically.
I'm using spring for property file mnmgt.
Can anyone help me with a nice generic way to do this?
I'd like to create a Bot using the FormFlow with JSON Schema approach. However, I need a bit more flexibility for displaying the answer options, since those need to be whole sentences and not only single words.
Is it possible to extend the enums specified inside the JSON file with descriptions that will be offered as options instead of the enum itself?
As I understand this is possible in code by using the Describe-Attribute.
You could use the "Define" property with custom script. The Sandwich Bot example is doing it this way (from json-schema-example):
"Define": "field.SetType(null).AddDescription(\"cookie\", DynamicSandwich.FreeCookie).AddTerms(\"cookie\", Language.GenerateTerms(DynamicSandwich.FreeCookie, 2)).AddDescription(\"drink\", DynamicSandwich.FreeDrink).AddTerms(\"drink\", Language.GenerateTerms(DynamicSandwich.FreeDrink, 2)); return true;",
Reading the API Blueprint specification, it seems set up to allow one to specify 'Data Structures' like:
Address
street: 100 Main Str. (string) - street address
zip: 77777-7777 (string) - zip / postal code
...
Customer:
handle: mrchirpy (string)
address: (address)
And then in the model, make a reference to the data structure:
Model
[Customer][]
It seems all set up that by referencing the data structure it should generate documentation and examples in-line with the end points.
However, I can't seem to get it to work, nor can I find examples using "fully normalized data abstraction". I want to define my data structures once, and then reference everywhere. It seems like it might be a problem with the tooling, specifically I'm using aglio as the rendering agent.
It seems like all this would be top of the fold type stuff so I'm confused and wondering if I'm missing something or making the wrong assumptions about what's possible here.
#zanerock, I'm the author of Aglio. The data structure support that you mention is a part of MSON, which was recently added as a feature to API Blueprint to describe data structures / schemas. Aglio has not yet been updated to support this, but I do plan on adding the feature.
If I want to create a entity in Core Data that has attributes with values that should be localizable I'm wondering how the most efficient way would look like?
As a example let's assume the following structure:
Book
name (localizable)
description (localizable)
author
An localized book entry would look like this:
name: "A great novel" (en/international),
"Ein großartiger Roman" (de),
"Un grand roman" (fr)
description:
"Great!" (en/international),
"Großartig!" (de),
"Grand!" (fr)
author: "John Smith"
In a SQL/SQLite implementation I would use two tables. A books table containing the book information (author, the english/international name and description) and the localizationBooks table that is related using the primary key of the corresponding book. This second table contains the localized name and description values as well as the languageCode. This would allow to have a scalable number of localizations.
For fetching the data I would use a
SELECT COALESCE(localizationBooks.name, books.name)
to get the actual values for the given language code. This allows to use the international english value as fallback for unsupported languages.
Would this require a separate entity in Core Data (e.g. BookLocalization) that has a relation to the Book or is there another recommended way of doing this?
The strategy you mention is usually the best. As you suggest, this requires an extra entity for the localized properties.
You can then write a helper method on your Books entity to get the appropriate localization object for a given language and use it like this:
[book bookLocalizationForLanguage:#"de"].name
You could even take it a step further and just add properties like localizedName, localizedDescription on the Books entity which will fetch the appropriate localized value.
Well, despite that this topic is 3 years old... I just stumbled upon it, asking my self the very same as the original poster. I found another thread with an answer.
I'll just repeat it in here in case somebody else hits this thread (Answer from Gordon Hughes):
Good practices for multiple language data in Core Data
To summarize:
Let's say you have Entity Books. Then you will have to make an additional one, called Localizedbook for example. In Books you have the attribute "title" and in LocalizedBook you have "localizedTitle" and "locale" for international strings like "en_US".
You now have to set the relationship between title -> localizedTitle (one to many, as one original title can have multiple translations).
So, every time you fetch "title" you will get the "localizedTitle" given to a specific locale, if the relations are set correctly.