gettext() is really intended to translate UI elements, it’s not for multi-lingual site content. A help page is content, not a UI element, so it should be handled like other content on the site would be handled.
In the case of help pages for plugins or themes, we cannot know how content is handled. IMO in such cases, it’s best to provide online multi-lingual help through your own site and merely link to it on your plugin or theme.
I would think there are other solutions. It would be informative to hear about what others are doing to address this. Other than not providing any help :>
The purpose of gettext is to localize everything in a page that was put there by WordPress core, the theme and any plugin. It is NOT about translating anything that was input by the user (the content).
So do you need to create a whole web site in just one language, different than “English (US)”?
That’s easy: Just select which language you want for the whole web site under settings – general. In the personal profile settings, a user may still opt to have the admin interface in English.
Or do you want to include just one page in a specific language but have everything else in English? Then just write that page in the different language, and you´re done. Note, however, that in this case the parts of the page that come from the theme will stay in English. (Things like “written by”, “there are x comments”, “leave a comment”, etc.)
Or do you want to create a multilingual site where you´re going to put the same content in more than one language? In this case, you´ll need a multilingual plugin. It will switch the language setting before every page is presented to the visitor and will maintain links between the different language versions. The two mostly used plugins for this are: Polylang (a free plugin) and WPML (a commercial solution). Personally, I happen to currently use a third one: Qtranslate-X (also free), but this one seems to currently lack support from a devoted developer.
These plugins make sure that the whole experience is created in the right way. If you switch to, say, Arabic, then they will even invoke the RTL-part of your theme (provided that your current theme is correctly prepared for RTL languages).
“best to provide online multi-lingual help through your own site”
That’s what Joomla is doing for their core and this keeps it up-to-date for all installations. However it may be too taxing for an individual casual developer to maintain such a site. It would make sense to let end-users customize or add to the help info as they may see fit which makes an argument for a distributed help files.
I looked into the admin help screen. There may not be enough room (I have pictures) and localization is still an issue.
I am starting to lean toward self-contained help files with the path being switched depending on the users locale.
“So do you need to create a whole web site in just one language”
No, this is not about creating a site, this is about making a plugin, or a theme, and figuring out the best way to internationalize its help pages.
