That way, the format can be standardized and the code can be reused among
other translatable objects such as the knowledge base.

Store a complex text with title and body combined with ASCII 0x04 byte
(field seprator).

This will help if the user has "Browser Preference" selected as the
preferred language. When email correspondence needs to be sent to the user,
the browser_lang extra attribute can be used as a backup to to the user's
language preference in the event that the language preference is set to auto
(Browser Preference).

to indicate the primary language expected for translatable content

The solution is simple: upload the image, create the draft automatically,
attach the image to the draft, return the draft_id to the client. That's it.
There's no more need to create the draft in advance now.

Instead, only show the box if the draft has been modified since initially
created / updated.

Drafts now are placed directly into the HTML response. The response contains
the draft information as well as the original content saved in the database
for the content being modified. The draft itself is placed into the redactor
box rather than the current content.

This patch also reduces some of the [Draft Saved] notices where there is no
content or the content has not yet been modified.

After testing 1.9.4 I noticed that these strings are not yet included in the translation. So this is the (hopefully correct) pull request to add them ;)

There was a slight issue when transitioning from a short answer field to a
drop-down field, and when the CDATA table is dropped and rebuilt.

Prior to osTicket v1.9.4, drop down lists only allowed for a single entry.
After upgrading to 1.9.4 the database data for drop downs changed to allow
for multiple entries. However, the old data format was not properly handled
by the SelectionField::to_php() method which handled interpreting and
upgrading the database data.