Have a menulist preference in my addon and I'm trying to localize it.
The preference works fine from a functional point of view but when I change my browser's locale to es-ES, I still see the English translations.
Is there a declaration error here?
The official documentation does not give full examples of it's usage.
https://addons.mozilla.org/en-US/developers/docs/sdk/latest/dev-guide/tutorials/l10n.html
package.json:
{
"name": "extensions.savetexttofile.saveMode",
"title": "Save mode?",
"type": "menulist",
"value": 0,
"options": [
{
"value": "0",
"label": "Create new file"
},
{
"value": "1",
"label": "Append to existing file"
}
]
}]
tail -n 4 locale/es-ES.properties:
extensions.savetexttofile.saveMode_title= modo de ahorro de?
extensions.savetexttofile.saveMode_description= Método para guardar texto:
extensions.savetexttofile.saveMode_options.0= Crear un archivo nuevo
extensions.savetexttofile.saveMode_options.1= Añadir a un archivo existente
For options, you must use the label of the option in your properties file, like so (tested):
extensions.savetexttofile.saveMode_title= modo de ahorro de?
extensions.savetexttofile.saveMode_description= Método para guardar texto:
extensions.savetexttofile.saveMode_options.Create new file= Crear un archivo nuevo
extensions.savetexttofile.saveMode_options.Append to existing file= Añadir a un archivo existente
This looks kinda nasty, so it might be advisable to use a "generic" name in your package.json like createand append and localize that as saveMode_options.create= in all locales, including your en-US.properties.
On an unrelated note: It is not necessary to prefix your SDK prefs with extensions.savetexttofile.. The add-on SDK already prefixes it with your add-on id, so that you end up with a double prefix like extensions.jid1-pL3SKrUpOJo04Q#jetpack.extensions.savetexttofile.saveMode)
Related
We are trying to build a multilingual chatbot which supports English (en-us) as well as German (de-de). We had been using it on Microsoft Teams without any problems until around mid-June 2020. Thereafter, we noticed that the localization didn't work properly anymore. We also noticed that this was around the same time that Teams introduced manifest version 1.7. The following occurrence is observed:
If the Teams admin uploads the app while their MS Teams client language is en-us, all custom applications ignore the 'de-de' localization info, and all information, as well as commands, are displayed in English only, even if the client language for the users is German.
The exact opposite will happen if the language of the admin was de-de when they uploaded the application. All information from the bot will be in German, whereas the default language (English) will be ignored.
As a sample, I am sharing this screenshot.
Here, you can see that although the client language is German, the suggestion commands appear in English. In fact, the bot name and description are also in English. In fact, we observed that the same behaviour is also exhibited for the official manifest template from Microsoft.
Here are our manifest files:
manifest.json
{
"$schema": "https://developer.microsoft.com/en-us/json-schemas/teams/v1.7/MicrosoftTeams.schema.json",
"manifestVersion": "1.7",
"version": "1.0.0",
"id": "00000000-0000-0000-0000-00000000000",
"packageName": "com.sample.sample.sample.dev.bot3",
"developer": {
"name": "Sample Inc.",
"websiteUrl": "https:/sample.z6.web.core.windows.net",
"privacyUrl": "https://sample.z6.web.core.windows.net/privacy.html",
"termsOfUseUrl": "https://sample.z6.web.core.windows.net/tou.html"
},
"localizationInfo": {
"defaultLanguageTag": "en-us",
"additionalLanguages": [
{
"languageTag": "de-de",
"file": "de-de.json"
}
]
},
"icons": {
"color": "color.png",
"outline": "outline.png"
},
"name": {
"short": "Manifest Test EN",
"full": "Manifest Test EN Bot"
},
"description": {
"short": "Manifest Test EN",
"full": "Manifest Test EN Bot"
},
"accentColor": "#40497E",
"bots": [
{
"botId": "00000000-0000-0000-0000-00000000000",
"scopes": [
"personal"
],
"supportsFiles": true,
"isNotificationOnly": false,
"commandLists": [
{
"scopes": [
"personal"
],
"commands": [
{
"title": "Personal Command 1",
"description": "Description of Personal Command 1"
},
{
"title": "Personal Command N",
"description": "Description of Personal Command N"
}
]
}
]
}
],
"staticTabs": [
],
"permissions": [
"identity",
"messageTeamMembers"
],
"validDomains": [
"sample.z6.web.core.windows.net",
"token.botframework.com"
]
}
Localization file de-de.json
{
"$schema": "https://developer.microsoft.com/en-us/json-schemas/teams/v1.7/MicrosoftTeams.Localization.schema.json",
"name.short": "Manifest Test DE",
"name.full": "Manifest Test DE Bot",
"description.short": "Manifest Test DE",
"description.full": "Manifest Test DE Bot",
"bots[0].commandLists[0].commands[0].title": "Persönlicher Befehl 1",
"bots[0].commandLists[0].commands[0].description": "Beschreibung des persönlichen Befehls 1",
"bots[0].commandLists[0].commands[1].title": "Beschreibung des persönlichen Befehls N",
"bots[0].commandLists[0].commands[1].description": "Das ist DE1"
}
We are experiencing the same issue here only we have been able to determine that the language the app is shown to the user is the language the app is installed with.
So in your case the app was propably installed when your Teams language was set to German, if you would now switch to another language the app would still be in German. We have tried this for multiple apps, multiple users and multiple tenants. The language used is always the one from the client the app is installed from, not the language the current user is using.
So for example when a App is installed with a client that is for example in German, the app will be configured in German for this user and all other users of the tenant the app is installed for. If the user that installed the app switched language (fe: English) to another supported language the language stays in German (even when the client is restarted). The same goes for other users, if a user at the moment of installation for example was using the application in English then the app will also be in German for that user and not English since it was installed by a user who had German as it's default language.
Could you please try updating the version to 1.2 in the manifest?
here is the result after updating the version
Description: Teams display wrong values in app static tab and 'what can i do' input command
For example,value 'élément' display '�l�ment',it seems that Teams can not recognize the char 'é'
Manifest Version: 1.5
Language: fr-fr
Manifest.json
{
//hide bot other message
"localizationInfo": {
"defaultLanguageTag": "en",
"additionalLanguages": [
{
"languageTag": "fr-fr",
"file": "fr-fr.json"
}
]
}
}
fr-fr.json
{
"$schema": "https://developer.microsoft.com/fr-fr/json-schemas/teams/v1.5/MicrosoftTeams.Localization.schema.json",
"name.short": "Test",
"name.full": "TestFullName",
"description.short": "short description example",
"description.full": "full description example",
"staticTabs[0].name": "Nouveautés",
"bots[0].commandLists[0].commands[0].title": "Restaurer élément",
"bots[0].commandLists[0].commands[0].description": "Restaurer élément for test",
}
This issue has been solved when I check the installer bot package.It seems that the App Studio can not recognize some words like 'é'. So close this issue!
#Lin's Master, for all the French regions, you need to set your "languageTag" = "fr". Please follow this documentation.
I'm working on a multiple-language website and I'm preparing Schema.org markups using JSON-LD. Important detail: this website uses subdirectories for languages. Let's consider 2 languages:
English: https://www.example.com/
French: https://www.example.com/fr/
I want to put Corporation and WebSite things on all localized HP. Everything goes fine but for #id, url and inLanguage properties: I don't quite know what I should fill.
For Corporation, I think I got it right: I'm going to use on all pages default url and base my #id on it:
{
"#context": "http://schema.org",
"#type": "Corporation",
"#id": "https://www.example.com/#organization",
"name": "Example",
"url": "https://www.example.com/",
...
But what would be the best move for WebSite properties, on my French HP?
Technically speaking, /fr/ subfolder is part of the example.com/ domain. But then, #id, inLanguage and url are not telling my website is also available for French-speakers.
{
"#context": "http://schema.org",
"#type": "WebSite",
"#id": "https://www.example.com/#website", // should this be "https://www.example.com/fr/#website" ?
"name": "Example",
"url": "https://www.example.com/", // should this be "https://www.example.com/fr/" ?
"inLanguage": "en", // should this be "fr" ?
...
I searched a lot about this and found nothing on this particular matter.
Does anyone have any experience on this?
You have two different (albeit translated) websites. It shouldn’t matter that they share the same domain/hostname.
Each website should get its own WebSite item, with its own #id, url, and inLanguage values, while they would refer to the same Corporation item.
{
"#context": "http://schema.org",
"#type": "WebSite",
"#id": "https://www.example.com/#website",
"url": "https://www.example.com/",
"inLanguage": "en",
"publisher": {"#id": "https://www.example.com/#organization"}
}
{
"#context": "http://schema.org",
"#type": "WebSite",
"#id": "https://www.example.com/fr/#website",
"url": "https://www.example.com/fr/",
"inLanguage": "fr",
"publisher": {"#id": "https://www.example.com/#organization"}
}
If the websites are primarily translations, you could use workTranslation/translationOfWork to link the WebSite items.
"workTranslation": {"#id": "https://www.example.com/fr/#website"}
"translationOfWork": {"#id": "https://www.example.com/#website"}
(This is a good case to see why the WebSite items should have different #id values, because otherwise you couldn’t refer to their translations like that. Using the url value instead of the #id value wouldn’t be a good idea, because this URI typically represents the homepage, not the whole website.)
I already read answers about placing a
default.properties
file or a
package.properties
, and even that the browser already detects the unique language as default, but it is not working.
I have my browser configured in french, and my partner had it in english. We are just implementing the extension in english, but when I run the extension in the french browser, it doesn not load anything.
I also read about having some properties in the package.json like:
"locales": {
"en": {
"name": "Open Web",
"description": "Come on!"
},
"fr": {
"name": "L'Open Web",
"description": "Allez!"
}
},
"default_locale": "en"
But didn't work.
I'm using last stable version of Firefox 42.0b1. Any idea?
You need to have a default en-US.properties file. That's the default if the user language is not supported by your extension.
I need to get the highway name on which the user is currently navigating.
That can be done in navigation mode, getting it from
-(void)routingService:(SKRoutingService *)routingService didChangeCurrentStreetName:(NSString *)currentStreetName streetType:(SKStreetType)streetType countryCode:(NSString *)countryCode
So, when I was testing my app yesterday, I was on the highway, and yes, Skobbler did recognised that I am on one, and yes, I got the Highway name back.
It was "Brooklyn-Queens Expressway".
But, Brooklyn-Queens Expressway is actually name of the I-278 Interstate highway, and all the functions I would later have to use, need to get Highway name in that format I-nnn
Here is the map photo of what I mean
So, Is there a way to get streetName in that I-nnn format, when the streetType is recognised as an interstate highway?
Or is there any Open Streetmap database we could consult? I wasn't able to find anything on OSM Wiki.
Don't know about the Skobbler SDK, but if online query is available and you have the approximate geographical area and the name of the motorway, you may use the Overpass API (http://wiki.openstreetmap.org/wiki/Overpass_API) to query the openstreetmap database for the highway reference.
For example, the following query (for a particular bbox which contains a small section of the highway):
[out:json]
[timeout:25]
;
(
way
["highway"="motorway"]
["name"="Brooklyn-Queens Expressway"]
(40.73483602685421,-73.91463160514832,40.73785205632046,-73.9096748828888);
);
out body qt;
returns (with some key-value pairs omitted for simplicity):
{
"version": 0.6,
"generator": "Overpass API",
"osm3s": {
"timestamp_osm_base": "2015-09-18T20:21:02Z",
"copyright": "The data included in this document is from www.openstreetmap.org. The data is made available under ODbL."
},
"elements": [
{
"type": "way",
"id": 46723482,
"nodes": [
488264429,
488264444,
488264461,
488264512,
488264530,
488264541,
597315979
],
"tags": {
"bicycle": "no",
"bridge": "yes",
"foot": "no",
"hgv": "designated",
"highway": "motorway",
"horse": "no",
"lanes": "3",
"layer": "1",
"name": "Brooklyn-Queens Expressway",
"oneway": "yes",
"ref": "I 278",
"sidewalk": "none",
}
},
{
"type": "way",
"id": 46724225,
"nodes": [
597315978,
488242888,
488248526,
488248544,
488248607
],
"tags": {
"bicycle": "no",
"bridge": "yes",
"foot": "no",
"hgv": "designated",
"highway": "motorway",
"horse": "no",
"lanes": "3",
"layer": "1",
"name": "Brooklyn-Queens Expressway",
"oneway": "yes",
"ref": "I 278",
"sidewalk": "none",
}
}
]
}
Which are 2 sections of the road in the osm database. In the US the "ref" tag for interstates is in the form "I XXX" (See http://wiki.openstreetmap.org/wiki/Interstate_Highways and note the format for co-location). You can retrieve the interstate name accordingly.
You can try the above query in overpass-turbo (a UI for the service) at http://overpass-turbo.eu/s/bxi (Press RUN and the DATA tab for the returned data, and pan the map for query in another bbox).
The "ref" information is not exposed in the SDK (will put this on the TODO list).
A workaround would be to look in the text advices (when using TTS) as this information is there (if you look at the $ref parameter, that contains the information you are looking for).
For more details regarding the text advices structure, see this blog article.