Assigned
Status Update
No update yet.
Comments
[Deleted User] <[Deleted User]>
I have one question related to Google translate API. but it is not related to this issue.
When i am trying to access Google Translate API using javascript when the query string size is around 13000 characters i am getting server response error code 400. Can you please let me know what is the request size limit if any exist.
When i am trying to access Google Translate API using javascript when the query string size is around 13000 characters i am getting server response error code 400. Can you please let me know what is the request size limit if any exist.
pa...@google.com
@vrames
according to Google API FAQ
The maximum size of each text to be translated is 5000 characters, not including any HTML tags.
according to Google API FAQ
The maximum size of each text to be translated is 5000 characters, not including any HTML tags.
pa...@google.com
N/A
[Deleted User] <[Deleted User]>
I also have a same problem some html tags who are divided in few tags , and it's problematic .. there is some news about it ??
pa...@google.com
I met with the problem just now, it seems the bug nof fixed yet.
[Deleted User] <[Deleted User]>
Update: I found the bug triggered not only by anchor tag, but also others. It seems that the problem is the context, and when I replace the tag with special symbol, 【】 for example, it worked.
In some context:
<a id="text">bla bla...</a> -> <a id="text">alb</a>alb<a id="text">...</a>
after change anchor tag to 【】,it worked:
【bla bla ...】 -> 【alb alb ...】
In some context:
<a id="text">bla bla...</a> -> <a id="text">alb</a>alb<a id="text">...</a>
after change anchor tag to 【】,it worked:
【bla bla ...】 -> 【alb alb ...】
pa...@google.com
pa...@google.com
This same issue exists for <span> tags. If I send the translate API a document consisting of text in span tags, each with a unique id, the result comes back with many of the span tags mixed up, nested and duplicated. A partial example from a test document, translated from German to English:
Input: <span id='1'>Per </span><span id='2'>Web-ERV</span><span id='3'>Handelsgericht Wien</span><span id='4'>Marxergasse 1a</span><span id='5'>1030 Wien</span><span id='6'>Firmenbuchsache</span>
Output: <span id='1'>Via</span> <span id='2'>web ERV</span> <span id='3'>Vienna Commercial Court</span> <span id='4'>Marxergasse 1a</span> <span id='5'>1030 <span id='6'>Wien</span></span> <span id='6'>Commercial thing</span>
Notice above in the output from the API, there is now an extra <span id="6"> now nested in <span id="5">, around partial content of <span id="5">.. This is completely unacceptable for a paid service, html translation is completely unusable with this bug.
Input: <span id='1'>Per </span><span id='2'>Web-ERV</span><span id='3'>Handelsgericht Wien</span><span id='4'>Marxergasse 1a</span><span id='5'>1030 Wien</span><span id='6'>Firmenbuchsache</span>
Output: <span id='1'>Via</span> <span id='2'>web ERV</span> <span id='3'>Vienna Commercial Court</span> <span id='4'>Marxergasse 1a</span> <span id='5'>1030 <span id='6'>Wien</span></span> <span id='6'>Commercial thing</span>
Notice above in the output from the API, there is now an extra <span id="6"> now nested in <span id="5">, around partial content of <span id="5">.. This is completely unacceptable for a paid service, html translation is completely unusable with this bug.
pa...@google.com
pa...@google.com
Hi there,
any update on this one?
any update on this one?
[Deleted User] <[Deleted User]>
Hi,
This issue is also affecting a user in case number 17353456.
Is there any update?
This issue is also affecting a user in case number 17353456.
Is there any update?
Description
This will create a public issue which anybody can view and comment on.
Problem you have encountered:
More relevant jobs are not showing in relevant order. The search results display remote jobs first which is expected to be less relevant and go in the down order.
What you expected to happen:
Mote relevant jobs should be shown in the top order in the search result.
Steps to reproduce:
1- Go to search.indeed.jobs 2- Perform a Keyword Search of "software engineer" and a Location Search of "Tokyo, Japan" =>https://search.indeed.jobs/main/jobs?location=Tokyo,%20Japan&woe=7&stretchUnit=MILES&stretch=10&page=1&limit=100&keywords=software%20engineer&sortBy=relevance
3- You will see the first results are reqs that are remote not jobs located in Tokyo
Other information (workarounds you have tried, documentation consulted, etc):
It seems like Tokyo is being recognized as a 'State' level location, which is why the behavior is a little strange here. (The taxonomy is a little strange here since Japan's own location taxonomy is a little different than in the west.)
Workaround:
Search with a more specific (lower level) location in the location box for the search. Example ("Shinjiku, Tokyo, Japan") or getting more specific/ close to the (lower level) location.
ETA:
Currently the product engineering team is working on the fix and the similar behavior for state level locations to be accommodated in the next release.
There is an ETA of the fix and the production release road-map. It should be fixed in the next release, which is planned for early March.