The simplest solution is to:
- encode the secret phrase into one or more numbers, and
- then share each of those numbers using a secret sharing scheme.
In fact, if your secret phrase is stored on a computer, the first part is already taken care of: computers typically store data, including text, as sequences of 8-bit bytes — i.e. numbers from 0 to 255.
As long as you don't need to generate more than 255 shares of any secret, you can just treat those bytes as elements of GF(28) and share them using Shamir's secret sharing scheme (or any other similar secret sharing scheme you prefer).
You can even safely use the same share ID (i.e. $x$ coordinate) for each byte of the shared phrase, so that your shares will only be one byte longer than the secret phrase. (They'll be random binary data, though, so you may need to e.g. Base64 encode them for transport as text.) And Shamir's secret sharing over GF(28) can be made very fast, since all the math is done using just single bytes. For these reasons, quite a few implementations of Shamir's secret sharing do just this.
The byte-by-byte sharing method described above does have a few disadvantages:
It reveals the byte length of the secret phrase. If this is an issue, the phrase should be somehow reversibly padded to a fixed length before sharing.
For mathematical reasons (i.e. because each share needs a distinct non-zero field element as its $x$ coordinate) it cannot be used to generate more that 255 distinct shares for each secret. If this is not enough, you can e.g. split the share into pairs of bytes and share it using Shamir's scheme over GF(216) for up to 65535 shares, or split it into groups of four bytes and share them over GF(232) for up to about 4 million shares.
(Of course you could use even bigger field sizes, or even sizes that are not powers of 2, if you wanted to. But there's generally little reason to do so, at least not when sharing binary data, which all data stored on a binary computer ultimately is.)
Of course, if you don't insist of perfect information-theoretic security, another practical option is to generate a random key (of e.g. 128 or 256 bits) for a symmetric encryption scheme such as AES,* encrypt your secret using the key, and then share the key.
This can be advantageous if your actual secret is very long (say, a video file) and if you can publish the encrypted secret on some shared channel, since then the only thing you'll need to send separately to each shareholder is their share of the key (which will only be a few bytes long).
*) Using a secure mode of operation, of course. I'd generally recommend an authenticated encryption mode like SIV, but even a classic non-authenticated mode like CBC or CTR may be sufficient for your needs. Just don't use ECB.