Google started “Google Neural Machine Translation” system in 2016 and improved the efficiency of translation of some languages tremendously. These languages include German, French, Spanish, Portuguese, Chinese, Japanese, Turkish and Korean; as they said.
However Dialogflow supports all of these languages except Turkish. Is there any specific reason for this exclusion?
Dialogflow does not handle translation, so Google's work in this area doesn't apply.
What Dialogflow does do that is language related is let you create sample phrases, in that language, and can handle other, similar, phrases that a user might make in conversation. So it isn't about translating a language - it is about natural language parsing and understanding.
Related
I'm currently working on a project that makes use of the Azure Speech API and I've seen the current documentation on language support. My two questions are...
Is there is a road-map somewhere for future additions to the language support list? Specifically, will there be an standard voice added for Urdu?
And also, for our South Asian friends. I know Urdu and Hindi are different written; but if I understand correctly, they are similar spoken. Are they similar enough to listen for Hindi (supported by Speech-to-text) for both?
We are developing a library for complex event processing.
Is there any standard or widely accepted language with clear semantics that we could based on?
After some research it seems all available options are vendor/platform specific.
Yes there is no common CEP language now, Most of the venders are either using a SQL like language or a UI based tool.
SQL like language seems to be the more feasible approach due to easy of development of a CEP engine,
We have tried to come up with a SQL like language for a Java based CEP engine.
This might be helpful for you.
Suho
Is there any free dictionary I can use for i18n?
Free as in open source / creative commons, ideally also for use in a commercial product.
Looking at the KDE i18n projects, they have translated a lot of applications in many languages. Is there a way I can use their dictionaries for a standard Qt (non-KDE) application - and am I allowed to?
You should contact the KDE localization team if you have questions about licensing of their translations.
I don't think that the l10n support of KDE applications will help yoiu directly -- they ship as a catalogue of strings, as appears in a particular context in the original application, and the translated form. There is a long way from that to automatically using the data in the context of another application, and that's also the reason why machine-generated translations have such a low quality. If you cannot speak a language and don't have anyone who could do the work for you, you won't be able to ship a working localized version in that language.
Does anyone know an online "software dictionary"? I want to translate my small application to other languages, it doesn't have much to translate, simple words like Save, Options, Username etc. I don't trust Google Translate to do it because software language is usually different... is there some kind of software language dictionary somewhere online? It's a freeware application so I cannot afford to hire someone to translate it for me and it has only like 20 phrases to translate...
Below are few resources
Rosetta - Ubuntu translation platform https://launchpad.net/
OpenOffice.org Localization Project http://l10n.openoffice.org/
Google Translation - http://translate.google.com/#
There is something like Microsoft Software Localization Dictionary, but I am unable to find it.
There is also a crowd-sourcing site which takes advantage of it as well as of Google Translate, but it is just a help for people that would like to translate your resources. You'll find this site on https://crowdin.com/ .
For typical words like "Open", "Save", "Close", "Back", "Next", etc. Microsoft's translation would be the best and you shouldn't have any problems localizing it by yourself...
I'm evaluating the Microsoft Anti-Cross Site Scripting Library (AntiXSS V3)
I have to say it seems to me that apart from providing a more comprehensive white list of acceptable characters, it's not really bringing anything to the party that a diligent programmer who encoded all his user/agent modifiable output wouldn't be doing anyway.
Am I missing a trick?
I don't think you're missing anything except for the fact that the number of programmers who are aware of proper secure coding is very small, and those that can do it properly are fewer still.
The libraries are written to make things easier for your average developer, and I would assume that any library that is written by Microsoft with the express purpose of enhancing security would be done by a coder (or team of coders) that are experts in the field, as opposed to your normal everyday developer who focuses on the needs of their company.
(I would think they would put a lot of importance on doing this right, considering how Microsoft products are always painted as being painted as "insecure" by MS-haters)
As a parallel, think about encryption. A diligent coder could come up with a secure encryption algorithm. However, OWASP guidelines tell you NOT to come up with your own algorithm, but to use tested algorithms developed by experts and well-tested.
If we have a tool by experts that does the job for it, why would we try to do this on our own? I'd say it would be good to use the Microsoft Anti-Cross Site Scripting Library for this reason alone, if it works as advertised.