I don't insist, but it might be a good idea to use array initializers here ([-LIBUSB_ERROR_COUNT] = "...")

I think we should spell 13 here as LIBUSB_ERROR_COUNT - 1

Parenthesized return value, as per style(9). While I'm thinking about this, I wonder if we should allow for holes in the translations. I'm thinking mainly for cases where we might add another error in the future; we'll have a NULL slot in other language maps until they get converted, and it probably makes sense to fallback to the english context for those individual entries.

nitems(libusb_language_ctx) and drop the local, please -- macro exists in sys/param.h if you need to pull that in.

Instead of breaking here, you might consider just setting default_language_context and returning LIBUSB_SUCCESS immediately, then assume the post-loop bits are an error path.

This formatting is valid, but I think it's a little jarring... IMO we should move the comment to the line above so that we don't have to wrap the name to the next line.

The link opens Microsoft Terminology Search. {F119859017}

New sentences should begin on a new line

It's also acceptable to move the declaration down to the for loop entirely these days, if you'd like.

I would like to leave it in the same place as it follws the style.

Maybe?

"Therefore" and "That means" have the same meaning, so you don't need to use both here.

sys/param.h is special, see style(9). It should always come first in the include list. All of the sys/* includes should appear before the rest, but that is an unrelated change. You should just add sys/param.h to the beginning for now, just before ctype.h.

Won't libusb_setlocale("abc") cause a segfault here? strchr() returns NULL if no match is found.