Without access to documentation, this is an exercise in reverse engineering.
You'd first want to figure out the physical properties of the programming link. Is it a serial or a parallel bus? Something you might probably infer from the number of pins. If in doubt, assume serial.
Electrically, that connection might simply be compatible with TTL, but they might also be differential, or totally different voltage levels, or actually a current-based scheme, and whatnot. Here, you'd however stand the best chance of finding documentation of other devices from the same series.
Then, you'd need to figure out what the signaling looks like. Is it something complex like UART (which is what your USB-to-serial device does, typically at TTL voltage levels), or something simple like SPI, where the programming has an explicit clock line to signify when the bits are to be read? Your best bet as forming a working hypothesis on that is to look how complicated the programming cable looks like, from when it is and how it connects to a PC. If it's old and looks simple, then it's (at most) only changing voltage levels, most likely, and whatever connection to the computer it uses is logically what it uses with the handset.
Figuring out the pin out on the HT is mostly an exercise in looking at which components connect to the programming connector on the board. For example, it would be pretty simple if you found an rs232 voltage converter chip in your HT that connects to the programming connector. That has definite Rx and tx pairs, and all you need to connect to it would be a PC with an RS-232 port configured to the same settings (baudrate, start and stop bits, parity, use of RTS/CTS), or a USB-to-serial converter with rs232 voltage levels, and the ability to work with the same settings (not every usb-to-serial converter even has rs232 support).
Once you're somewhat confident you found the right pins and a nice of communicating that won't physically damage HT or computer or adapter, you'd need to figure out the logical protocol. This would usually be covered in programming manuals, so maybe you find an old scan of one? If not, the usual way for industrial controls, and I'd guess also for programming old handsets, is getting a hold of the software, and running it in an emulator, looking what it tries to send to external devices, sending that, seeing what you get in response, using the emulated external interface to tell the software that it's what you got from the device, and repeat that until you understand what needs to be done.
Sometimes, such software is pretty resistant to such attempts - the emulator might not emulate the necessary platform exactly enough, things are too timing-sensitive, or the software just buggy. In that case, you'd disassemble the CPS and do a purely analytical reconstruction of how the software interacts with the HT.
Armed with that knowledge and a cheap logic analyzer, you'd prototype your own signal conversion if necessary and your own programming software, and iteratively improve it till you succeed in programming your HT :)
