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.
Kagi Translate
101–110 of 119 posts
Re: Kagi Translate
#102Re: Kagi Translate
#103Earlier 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.
Re: Kagi Translate
#104Earlier 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.
Re: Kagi Translate
#105Re: Kagi Translate
#106Earlier 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.
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
#107Disclaimer: 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…
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
#108On 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?
Other translation tools do not consider i. e. Kyrgyzstan an important market therefore do not put much effort into supporting Kyrgyz.
Re: Kagi Translate
#109Earlier 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).
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."