Excellent idea, this would be similar to the already existing APEX_UI_DEFAULT_UPDATE package.

I'm surprised this wasn't included in 3.x

Also,it would be great to have the possibility to choose the source of the help text.
=> Helptext based on SQL or PLSQL.

It would be nice to have a help-application available based on all the help entered. This helpapp should have search and index capabilities just like the old MS .chm files have.

This would be a good candidate for a Help feature which you could only enable (similar to the Feedback or Reporting features)

It would be great if some master-users are ablte to write the helptext for their colleagues.

Sooo… this simple idea was asked 10 years ago (!), and we still don’t have it…? :-(

I think this should be a feature in itself, similar to the feedback feature. I always start of building any app by implementing a way for end-users to manage application level and page level help entries. This should be standard functionality.

And Or provide bulk help text loader option in APEX builder.

Well overdue.  Help text typically needs to be written/edited by business users not developers

See FR-2945 for a declarative approach to this problem that supports a broader range of help text requirements than the API for static text management proposed here in FR-122.

Perhaps it could be implemented by allowing a Help text “callback” function, much like the error handler we can set at app level. That would us developers to pick the help text from custom tables or any other source we have…

Gets my vote (have build custom solutions for this too many times).

I disagree that this is a duplicate of the “Known duplicates” FR-2337Function returning string for Help Text & FR-2945Additional Sources for Page Item Help Text

FR-2945 and FR-2337 discuss providing a function to source help from wherever you want (local tables, REST APIs). This idea (FR-122) only talks about allowing you to update the help stored in APEX Builder via an API . Whilst also useful, these are two very different things. Allowing you to get help from wherever you want via a function call provides ultimate flexibility.

The team reviewed this idea again today. It's now possible to use text messages in help texts, and those are exportable in CSV or other formats. While it is not an API, it meets the requirement of having a separation of duty between the app meta data and the app content (help text).

@vincent morneau : In my opinion this doesn't not meet the requirement. For us it would be very helpful if the customer itself could maintain the help texts on its own, without requiring access to the APEX Builder. How can I do this today?

Additionally having the possibility to use text messages is not very convenient/efficient for single language applications.

The API exists today to update text messages, take a look at https://docs.oracle.com/en/database/oracle/apex/24.2/aeapi/APEX_LANG.UPDATE_MESSAGE-Procedure-Signature-2.html

Having a separate Help API would involve a similar API operation. You can even build an APEX app with a report (grid?) to update your app messages, and have your users edit the messages directly.

Thanks @vincent morneau  for your reply.

I know that, but you have the tedious task to add the message identifier to every Page-Item and create a text message for this before the help text could be edited via the API. 
Ok, one could provide a procedure to create text-messages for items with help texts with the special text-message reference semantic. 
But the tedious task to add the message identifier to every page item remains :-/

In a “Help Text Editor” application:
To avoid creating tons of page items, use an interactive grid like @vincent morneau said. Use the APEX_APPLICATION_TRANSLATIONS view to read them, then use a custom save process that executes APEX_LANG.UPDATE_MESSAGE on modified rows. Not exactly low code, but we were already talking about APIs.

Outside the “Help Text Editor” application:
Adding the message to every “public” page item is inevitable, and depending on how big of an application you're looking at, could be quite an undertaking. I don't see how this changes with a function call instead. Either way you'll have to edit the target page item to know where to look for help text.

The simplest way would be having the ability to define a help function similar to the way an APEX application error handling function is defined.  When Page item help is clicked on it passes the applicaiton ID, page ID, page Item, and data source to the help handling function that then returns help text.  Doesn't require touching all the page items / columns attributes to make help work unless there is a help attribute for on/off that defaults to off for the application.