Live data from Hacker News

Kagi Translate

blog.kagi.com

101–110 of 119 posts

Re: Kagi Translate

#101

Earlier quoted context omitted.

We are focusing most our resources on search (which I hope you can agree, we are doing a pretty good job at). And it turns out search is not enough and you need other things - like maps (or a browser, because some browsers will not let you change search engine and our paid users can not use the service). Both are also incredibly hard to do right. If it appears quarter-baked (and I am first to say that we can and will…

You do not need your own browser. Keep Firefox alive.

Mozilla is digging a grave for Firefox with its own hands, we need something else non-chromium, which Orion serves fine. I just wish they'd focus on fewer things as has already been mentioned, rather than producing many half-baked things.

Re: Kagi Translate

#102
post #77
post #64

Earlier quoted context omitted.

Interesting. Never had such an issue with Google. How do they do it?

By not having a puzzle-less/unsolvable captcha, or what do you mean?

Yes, exactly they don’t have it. Of course there must be a reason for that. Any other tech for example?

Re: Kagi Translate

#103

Earlier quoted context omitted.

You do not need your own browser. Keep Firefox alive.

Mozilla is digging a grave for Firefox with its own hands, we need something else non-chromium, which Orion serves fine. I just wish they'd focus on fewer things as has already been mentioned, rather than producing many half-baked things.

I have high hopes for ladybird being our savior in this regard.

Re: Kagi Translate

#104

Earlier quoted context omitted.

love the plan, but i’d suggest being more up front with users on how “finished” a product is. With the maps example, you run into problems because of expectations. If you slap a BETA or ALPHA logo on the maps product, expectations will be lower, and people are more forgiving of issues while you continue improving the product. Or if it’s only good in the US (just an example), make it clear somehow when searching for a…

Interestingly we do not get a lot of bug reports for Maps on our feedback forum. And this is where we tend to go to look for problems to fix.

As an anecdatapoint, I have replaced the button with a redirect to Google maps. It's not worth trying to extract value from the Kagi one, I probably gave it a chance ~20 times and I don't think it did what I needed a single one. (In Scandinavia)

Re: Kagi Translate

#105
Any plans to include that directly into android app? Feels fairly obvious to me as a user - I went there automatically after the news dropped, but.... not there yet ;)

Re: Kagi Translate

#106

Earlier quoted context omitted.

love the plan, but i’d suggest being more up front with users on how “finished” a product is. With the maps example, you run into problems because of expectations. If you slap a BETA or ALPHA logo on the maps product, expectations will be lower, and people are more forgiving of issues while you continue improving the product. Or if it’s only good in the US (just an example), make it clear somehow when searching for a…

Interestingly we do not get a lot of bug reports for Maps on our feedback forum. And this is where we tend to go to look for problems to fix.

Like others here are saying, Kagi maps is so far behind that I wouldn't bother with any bug reports or feedback. I tried it just now, was panning around in a region in Europe, clicked the "Hotels" button to see what it would present and get sent to a town called Hotels in Palestina with a Wikipedia description of what a hotel is...

So the suggestion to slap a beta sticker over maps is a good one. Nokia, Microsoft and Apple have all tried to compete with Google Maps without succeeding. Do yourself a favour and start using the Google Maps API for Kagi Maps, that's probably the only way you can get all the important data. If the API is expensive, then charge more for maps. Kagi customers want the best product, and are willing to pay for it.

Re: Kagi Translate

#107

Disclaimer: I am already a Kagi customer. At least for Afrikaans I'm not impressed here. There are some inaccuracies, like "varktone" becoming "pork rinds" instead of "pig toes" and also some censorship ("jou ma se poes" does NOT mean "play with my cat"!). Comparing directly against Google Translate, Google nails everything I threw at it. I didn't see any option to provide feedback, suggested translations, etc, but I…

> some censorship

How the hell is everyone okay with it?

Why should I be "forbidden" from understanding a text written in a foreign language if it contains something inappropriate?

I don't know of any translation service that does censorship.

Not even Google does it and Kagi was supposed to be less user hostile than Google, not more.

Re: Kagi Translate

#108

On the sidenote, does anyone know what methods Yandex use? When I'm trying to translate Kyrgyz, Google Translate shows utter trash that makes less sense than if they chose words at random. Yandex in comparison is very impressive. What's the secret ingredient?

There is no secret ingredient, Yandex just put more effort into supporting languages that are spoken in ex-USSR countries, because that's the most important market for them.

Other translation tools do not consider i. e. Kyrgyzstan an important market therefore do not put much effort into supporting Kyrgyz.

Re: Kagi Translate

#109

Earlier quoted context omitted.

Indeed, that's what would make most sense to me. I also strongly suspect the way they're able to make it free is by caching the results, so each translation only happens one time regardless of how many requests for the page happen. If they translated dynamic content, they couldn't (safely) cache the results.

I don't think JS vs HTML would make any difference to caching. If they are caching by URL you can have dynamic HTML generation or a JS generated page that is the same on every load. If you are caching by the text then you can do the same for HTML or JS generated (you are just reading the text out of the DOM when the JS seems done).

Yeah, js can be static or dynamic, so its not just whether it's js that matters. It's whether the content is added or modified after initial rendering that makes it dynamic.

Most js heavy pages retrieve data from APIs, and the static parts of the code is just layout and menus, which isn't the part that people care most about translating. Thus why GP said "added via Javascript later." The important part of that isn't the "Javascript" , it's the "later."

Re: Kagi Translate

#110
This is silly, and very tedious, to "Verify you are human" after each translation. How likely is that after few translations I might become a robot?
Post reply on HN