Email or username:

Password:

Forgot your password?
Alexey's posts Post Back to profile
Top-level
Alexey Skobkin
6 comments
FinchHaven

@skobkin

Attempting to translate your post from Russian (is it?) returns an http code

"503 Service Unavailable

The server is not ready to handle the request. Common causes are a server that is down for maintenance or that is overloaded."

Often this seems to happen on small instances:

fedidb.org/network/instance/lo

7 January at 0:19 | Open on sfba.social
Alexey Skobkin

@FinchHaven
Are you sure it's not your server responding with that?

I didn't check it out, but I don't think remote instances (ours in this case) are supposed to translate content. I'd bet that there's a problem with translation backend on your instance. For example if it's using LibreTranslate or something like that it could be unavailable right now. Our instance uses DeepL and when I tried to translate my post just now everything was fine.

7 January at 0:24 | Open on lor.sh
FinchHaven

@skobkin

No, i've just translated four or five posts in rapid succession and every one succeeded

The tip-off is the progress bar at the top of the Firefox tab

It creeps along, pauses, and then returns the 503

I doubt very strongly that's happening on my end, suddenly and out of the blue, and actually the quote is "remote data could not be fetched"

But maybe my instance is requesting a LibreTranslate response, which apparently your instance does not generate

And of course your translation on your instance would work for you

@skobkin

No, i've just translated four or five posts in rapid succession and every one succeeded

The tip-off is the progress bar at the top of the Firefox tab

It creeps along, pauses, and then returns the 503

I doubt very strongly that's happening on my end, suddenly and out of the blue, and actually the quote is "remote data could not be fetched"

7 January at 0:28 | Open on sfba.social
Alexey Skobkin

@FinchHaven
It's sounds strange.
There's really almost no sense for an instance to ask another instance to perform translations. It'll cause performance and security implications.
Also I'm not sure if I confused you with my reply, but LibreTranslate is an external service. It's not affiliated with our or your instances.
If I have time tomorrow, I'll check how mastodon handles translations. But most likely the translation is handled on the same instance where user which requested translation is registered. To be more precise, it's not directly handled there, but that instance goes to one of supported translation services (DeepL, LibreTranslate, Google Translate, etc) and asks to perform a translation. At least that's how I would implement it.
Also maybe the translation was unavailable for Russian only for example? When you said that you were translating several posts before, did you translate any from Russian?

@FinchHaven
It's sounds strange.
There's really almost no sense for an instance to ask another instance to perform translations. It'll cause performance and security implications.
Also I'm not sure if I confused you with my reply, but LibreTranslate is an external service. It's not affiliated with our or your instances.
If I have time tomorrow, I'll check how mastodon handles translations. But most likely the translation is handled on the same instance where user which requested translation is registered....

7 January at 0:38 | Open on lor.sh
FinchHaven

@skobkin

Yeah, I've wondered about this exact thing myself

It seems like a bizarre design decision to push translation of a local page back out to the remote instance it originated from

Why not just do translation on the local end, where the post already exists?

It's baffling

I follow Mastodon on Github but I missed the discussion when LibreTranslate was adopted and really don't know exactly on *which* end it takes place as an absolute fact

I'm just inferring all this from what I've observed since LibreTranslate was adopted on my instance

Again (don't know if you saw it) one real strong clue is the full text of the Mastodon popup in Firefox is (503: remote data could not be fetched)

And yes, I have translated from Russian and Japanese (Kanji, I think it is) successfully

I mentioned LibreTranslate because that's how successful translations are tagged on my end

Now I don't know, which always drives me nuts until I find out :0

@skobkin

Yeah, I've wondered about this exact thing myself

It seems like a bizarre design decision to push translation of a local page back out to the remote instance it originated from

Why not just do translation on the local end, where the post already exists?

It's baffling

I follow Mastodon on Github but I missed the discussion when LibreTranslate was adopted and really don't know exactly on *which* end it takes place as an absolute fact

7 January at 0:44 | Open on sfba.social
Alexey Skobkin

@FinchHaven
MOST LIKELY both DeepL and LibreTranslate implemented in Mastodon in the same way differing only in the "protocol" they use when communicating with translation service.

> it seem like a bizarre design decision

Not really. In most cases translation is not needed. So why would the origin node store unnecessary data? Even if it's "lazy" translation, it's not very useful to keep it there because most likely it won't be needed anymore. Also servers are often "regional". So most of the users speak the same language.
Furthermore server-to-server requests are not cheap, so adding another link to the chain (server1 -> server2 -> translation service) would not be optimal.

> from Russian and Japanese

Even stranger then.

@FinchHaven
MOST LIKELY both DeepL and LibreTranslate implemented in Mastodon in the same way differing only in the "protocol" they use when communicating with translation service.

> it seem like a bizarre design decision

Not really. In most cases translation is not needed. So why would the origin node store unnecessary data? Even if it's "lazy" translation, it's not very useful to keep it there because most likely it won't be needed anymore. Also servers are often "regional". So most of the users...

7 January at 0:56 | Open on lor.sh
Go Up