Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: CURL errors codes and messages - are they globalized?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dan Fandrich via curl-users <curl-users_at_lists.haxx.se>
Date: Thu, 16 Jan 2025 10:32:18 -0800
On Thu, Jan 16, 2025 at 02:25:37PM +0000, Michael Conners via curl-users wrote:
> If a CURLE_SSL_CONNECT_ERROR is returned from curl_easy_perform, the error text
> I see is "SSL connect error". What error text would a German user see?
>
> Are CURL error messages globalized? If so, which languages?
curl messages are not localized, although if you restrict yourself to libcurl
and avoid debug logs, there aren't actually very many full text messages that
you can get back. Actually, CURLOPT_ERRORBUFFER and the *strerror functions are
the only exceptions that I can think of. Both of those use a technical
vocabulary that generally don't make a lot of sense to nontechnical users, no
matter the language they appear in. I suspect that's why yours is the first
request I can remember about this topic.
The CURLcode errors are quite fine-grained, so applications can return a
useful localized message based on those codes quite easily. Digging in to a
error much further often means looking at not just the ERRORBUFFER messages
but debug logs as well, which poses a scalability problem for translation.
To get an idea of the total number of translatable messages that there might
be, there are currently about 102 curl_easy_strerror messages, 14 for
curl_multi_strerror, 6 for curl_share_strerror, 32 for curl_url_strerror, for a
total of 154 error codes. There are approximately 910 different messages that
can show up in CURLOPT_ERRORBUFFER. There are approximately 745 additional
debug logging messages. There are approximately 562 additional trace logging
messages. This also doesn't messages passed as-is from dependent libraries
(like OpenSSL's detailed errors). That totals about 2371 messages that would
need to be translated to provide an almost fully localized (text only) libcurl
experience. And that doesn't even include the curl front-end which has many
thousands more lines of text that it can output. Or the documentation, which wc
-l tells me is now over 102,000 additional lines.
Fully translating curl would be a huge undertaking on its own, not just in the
initial translation but more importantly in keeping the hundreds or thousands
(or a hundred thousand, if you want to go full in) of messages up-to-date for
each release in every language that we'd want to localize. Going half-way is
not a viable option because libcurl is used in so many applications that depend
on providing a polished result; leaving a few messages untranslated in each new
release would give the wrong impression. Once people start depending on
translations they are going to expect them to stay up-to-date. I doubt this is
something we'd want to take on as a project without a committed team available
to manage it. And given the dearth of interest in the topic, I don't see that
happening.
If users were to submit localized versions of curl_easy_strerror() (& the other
*strerror functions) in various languages, I could see them potentially being
included in the repo as unofficial examples. These functions are well-bounded
and don't change very often (only when new curl error codes are defined) and
are the ones that are the most likely to be displayed to users in localized
applications. Collecting them within the curl repo seems like it would be
useful to avoid many people translating the same things. I suspect there are
many cases out there of these specific messages already having been translated
for specific apps, so maybe there are people out there willing to submit them
for the benefit of others.
Dan
Date: Thu, 16 Jan 2025 10:32:18 -0800
On Thu, Jan 16, 2025 at 02:25:37PM +0000, Michael Conners via curl-users wrote:
> If a CURLE_SSL_CONNECT_ERROR is returned from curl_easy_perform, the error text
> I see is "SSL connect error". What error text would a German user see?
>
> Are CURL error messages globalized? If so, which languages?
curl messages are not localized, although if you restrict yourself to libcurl
and avoid debug logs, there aren't actually very many full text messages that
you can get back. Actually, CURLOPT_ERRORBUFFER and the *strerror functions are
the only exceptions that I can think of. Both of those use a technical
vocabulary that generally don't make a lot of sense to nontechnical users, no
matter the language they appear in. I suspect that's why yours is the first
request I can remember about this topic.
The CURLcode errors are quite fine-grained, so applications can return a
useful localized message based on those codes quite easily. Digging in to a
error much further often means looking at not just the ERRORBUFFER messages
but debug logs as well, which poses a scalability problem for translation.
To get an idea of the total number of translatable messages that there might
be, there are currently about 102 curl_easy_strerror messages, 14 for
curl_multi_strerror, 6 for curl_share_strerror, 32 for curl_url_strerror, for a
total of 154 error codes. There are approximately 910 different messages that
can show up in CURLOPT_ERRORBUFFER. There are approximately 745 additional
debug logging messages. There are approximately 562 additional trace logging
messages. This also doesn't messages passed as-is from dependent libraries
(like OpenSSL's detailed errors). That totals about 2371 messages that would
need to be translated to provide an almost fully localized (text only) libcurl
experience. And that doesn't even include the curl front-end which has many
thousands more lines of text that it can output. Or the documentation, which wc
-l tells me is now over 102,000 additional lines.
Fully translating curl would be a huge undertaking on its own, not just in the
initial translation but more importantly in keeping the hundreds or thousands
(or a hundred thousand, if you want to go full in) of messages up-to-date for
each release in every language that we'd want to localize. Going half-way is
not a viable option because libcurl is used in so many applications that depend
on providing a polished result; leaving a few messages untranslated in each new
release would give the wrong impression. Once people start depending on
translations they are going to expect them to stay up-to-date. I doubt this is
something we'd want to take on as a project without a committed team available
to manage it. And given the dearth of interest in the topic, I don't see that
happening.
If users were to submit localized versions of curl_easy_strerror() (& the other
*strerror functions) in various languages, I could see them potentially being
included in the repo as unofficial examples. These functions are well-bounded
and don't change very often (only when new curl error codes are defined) and
are the ones that are the most likely to be displayed to users in localized
applications. Collecting them within the curl repo seems like it would be
useful to avoid many people translating the same things. I suspect there are
many cases out there of these specific messages already having been translated
for specific apps, so maybe there are people out there willing to submit them
for the benefit of others.
Dan
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-01-16