I am using Google Cloud Translation API in one of my projects. I want to specify the gender for the translation. I am unable to find about this in Google Cloud Translation. I have also searched a lot on the Internet but not found any way to do this. I know how to specify the gender in Google Text to Speech API using the SSML, but I need it for the translation. Any help will be highly appreciated.
After much searching I have discovered that there is currently no way to do this.
I have made a feature request along these lines at the invitation of GCP support.
The documentation indicates that feature requests are prioritised by how often an issue is starred, so for now my best answer is to star the issue here so that they know how many people are interested in this.
Looking for the same...
As it is NMT (Neural Machine Translation), it reacts to context.
I tried many combinations and found that this works well so far (says, not 'to', not 'talk').
Examples are EN > ES
However, sometimes its effect doesn't reach far in the translation.
So you have to stick the 'prefix' before each sentence.
Sometimes you get irregular behavior (see lower case "estoy"). And when you change something irrelevant (to you, but not to the model) ... buala!
So the final version (for now) is:
I guess the point is:
Understanding how it works (Machine Learning Language Models)
The Model (Algorithm) they use is evolving, so you need to keep an eye, as what works today may break tomorrow.
Once you get the response you will have to filter out you 'prefix', but that is not too difficult.
Please comment if you find better ways (or the API gets updated).
Related info: https://ai.googleblog.com/2018/12/providing-gender-specific-translations.html
Related
I am building an Open Source Chrome extension based on Google translate (here).
I have read the other questions about Google translate API (like this one and this one) but I still don't have my answer.
I found several URLs for Google translate like these:
https://translate.googleapis.com/translate_a/single?client=gtx&sl=en&tl=fr&dt=t&q=father&ie=UTF-8&oe=UTF-8
https://clients5.google.com/translate_a/t?client=dict-chrome-ex&sl=en&tl=fr&dt=t&q=father
It seems all the URL are a different combination of 3 parts:
a base URL :
translate.googleapis.com/translate_a/
https://translate.google.com/translate_a/
https://clients5.google.com/translate_a/
the first argument after the translate_a/: either single or t
the clients which can be gtx, t or dict-chrome-ex [or apparently any ID]
So far I have seen differences in the JSON returned.
This https://translate.googleapis.com/translate_a/single?client=gtx&sl=en&tl=fr&dt=t&q=father&ie=UTF-8&oe=UTF-8 returns this json:
[[["père","father",null,null,1]
]
,null,"en"]
While this https://clients5.google.com/translate_a/t?client=dict-chrome-ex&sl=en&tl=fr&dt=t&q=father returns this json:
{"sentences":[{"trans":"père","orig":"father","backend":1},{"src_translit":"ˈfäT͟Hər"}],"dict":[{"pos":"noun","terms":["père"],"entry":[{"word":"père","reverse_translation":["father","dad","parent","papa"],"score":0.70910621,"previous_word":"le","gender":1}],"base_form":"father","pos_enum":1},{"pos":"verb","terms":["engendrer","concevoir"],"entry":[{"word":"engendrer","reverse_translation":["generate","engender","give rise to","beget","breed","father"],"synset_id":[52561],"score":0.00017133754},{"word":"concevoir","reverse_translation":["design","conceive","devise","plan","form","father"],"synset_id":[52561],"score":4.8327973e-05}],"base_form":"father","pos_enum":2}],"src":"en","alternative_translations":[{"src_phrase":"father","alternative":[{"word_postproc":"père","score":1000,"has_preceding_space":true,"attach_to_next_token":false}],"srcunicodeoffsets":[{"begin":0,"end":6}],"raw_src_segment":"father","start_pos":0,"end_pos":0}],"confidence":1,"ld_result":{"srclangs":["en"],"srclangs_confidences":[1],"extended_srclangs":["en"]},"query_inflections":[{"written_form":"father","features":{"number":2}},{"written_form":"fathers","features":{"number":1}}],"target_inflections":[{"written_form":"père","features":{"gender":1,"number":2}},{"written_form":"pères","features":{"gender":1,"number":1}},{"written_form":"père","features":{"number":2}},{"written_form":"pères","features":{"number":1}}]}
So my question is what are the (other than this one) differences between the different combinations given above.
In which case should I use one rather than the other (except for the returned JSON). Is there one that is depreciated or that supports more request?
For the meaning of the queries: https://stackoverflow.com/a/29537590/3154274
In regards to your actual question, I'm not sure there are any meaningful differences other than what you have stated and it would be difficult to determine if and when any of them are deprecated.
Given the APIs are undocumented and don't appear to be intended for usage in this manner, I don't think any of them should be considered for use in the development of a real application.
However, for solving your problem of finding a free human language translation API, I would recommend the Azure Translator Text API which provides translation of 2 million characters per month as part of their free tier.
For your specific use case, where I assume there may be a high amount of duplicate translations, I feel that caching the results would provide a significant benefit in reducing your usage amount.
When using the translation API, I get a different translation (and worse) than if I use translate.google.com.
I am working on a project for a client, and the client was dissatisfied with the translation and noticed the difference.
Do these two service use different engines? I read that the API uses nmt-mode now, and that translate.google.com already uses the same engine.
Both set to translate from Norwegian to English.
Any more information that can clear this up?
Thanks!
The result differences between the translate.google.com and the Translation API calls are considered as an expected behavior that can be generated due to maintenance tasks and the logic used by the internal processes; However, the engines used for each service seems to be private information.
Based on this, it is normal to get some variances when using the API. I think you can use the model parameter option as an available workaround in case you want to specify which of the available models to use, as well as take a look on the Specifying a model official documentation to get detail information about this alternative.
It's almost about 3 years later and the problem still remains!
So I was trying to translate a dataset with the Google Translate API, but in the end it failed to translate some texts to the target language (in my case, Persian/Farsi). So I decided to check them to see if there's a pattern and maybe translate them using the web version of Google Translate.
As I was doing so, I figured that the web version actually could translate some of those untranslated texts, BUT not all. When trying to find a reason for such behaviour, I found out that most of them were names and not sentences. But as we know, names can easily be written with the target language characters as the translation. But why the API doesn't transform those names while the web version does? This photo will explain everything perhaps:
verified translation
As can be seen, some translations have a badge indicating that the translation has been verified, while some others don't.
So to recap, my guess is that maybe the API is set to only use verified translations, but as for the web version, even unverified translations are allowed since you can edit or report them.
For some reason we still don't have this feature yet. We can make it work using zip codes, but how about City or State? The Views set of Modules are great and I would love to see Proximity Search options expanded. There are requests for this in the Drupal forums: http://drupal.org/node/489904 but that thread has been stagnant for months. The "fix" is inconsistent and no longer works on my end, using Views and Location series modules. Does anyone know a workaround to this issue? The custom module shown in Drupal forum worked at some point with limitations, but now its no longer displaying any search results. Trying to hit this from any angle -- have the US zipcodes in MySQL database for the former configuration; have Apache SOLR ready to go; even got Spatial SOLR ready to go if that ever picks up. Any help much appreciated.
I think one of the problems is city names are not necessarily unique. (zips are)
You could have the same city in different states.
For states, it's even less reliable because their area can vary a great deal and proximity search around a state would be very unreliable for states which don't have circular shapes.
So the module should have an extra step showing "did you mean.." results in case there are more returned (if possible).
I don't believe there is a workaround, it will require some coding to implement this in views.
I would start in location.views.inc around line #493, adapting the logic for the current zipcode handler. Look for the location_latlon_rough function in location.inc.
May be you have to try geoname module im not sure you should try
http://geonames.edesign.no/node/13
Give a try
Thanks,
Gobi :)
I can see where to get an rss feed for the BUG LIST, however I would like to get rss updates for modifications to current bugs if possible.
This is quite high up when searching via Google for it, so I'm adding a bit of advertisement here:
As Bugzilla still doesn't support this I wrote a small web service supporting exactly this. You can find its source code here and a running instance here.
What you're asking for is the subject of this enhancement bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=256718
but no one seems to be working on it.
My first guess is that the way to do it is to add a template somewhere like template/en/default/bug/show.atom.tmpl with whatever you need. Put it in custom or an extension as needed.
If you're interested in working on it or helping someone with it, visit channel #mozwebtools on irc.mozilla.org.
Not a perfect solution, but with the resolution of bug #255606, Bugzilla now allows listing all bugs, by running a search with no criteria, and you can then get the results of the search in Atom format using the link in the bottom of the list.
From the release notes for 4.2:
Configuration: A new parameter search_allow_no_criteria has been added (default: on) which allows admins to forbid queries with no criteria. This is particularly useful for large installations with several tens of thousands bugs where returning all bugs doesn't make sense and would have a performance impact on the database.
My team works mostly w/ Flex-based applications. That being said, there are nearly no conventions at all (even getting them to refactor is a miracle in itself) and the like.
Coming from a .NET + CruiseControl.NET background, I've been aching to getting everyone to use some decent tracking software (we're using a todo list coded in PHP now) and CI; I figured trac+BuildBot would be a nice option.
How would you convince upper management that this is the way to go, as well as some of the rules mentioned in this post? One of my main issues is that everyone codes without thinking (You'd be amazed at the type of "logic" this spawns...)
Thanks
Is there anything you could do now that wouldn't require permission from anyone else? Could you start by just using trac/buildbot/etc for just your own work, then add in others as they are interested?
In my experience you can get quite far by doing w/out asking.
Tell the management that they'll be better able to keep their eye on progress with such a tool.
Are there specific benefits to the route that you're suggesting that you could show them without them having to buy in?
I had an experience with getting my team to accept a maven + cruisecontrol CI setup. Basically I tried to get them to go along with it for a few days and they kept balking because it was unfamiliar. Then I just did it on my own and had all broken builds emailed to the mailing list. That night the project lead made a check in that broke the build (he just forgot a file) and, of course, everybody was emailed with his screw up.
The next day he came over to me and said, "I get it now."
It required no effort from him to get involved and got to see the benefits for free.