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.html
