if the bulk of the string literals are things internal to the program
(rather than intended for an end user), then it makes little sense to
move them to external resources (IME, most string literals tend to be
program internal anyways, with human-readable messages few and far
between, and most of these in-turn being internal debugging messages).
You must not work with large user-facing applications then.
My
practice is very nearly the opposite--most string literals are either
involved with debugging to log files, keys to preferences/other
configuration, or keys to human readable messages. The latter two
classes are things that tend to be grouped outside of the program itself
for simple reasons of reducing management complexity (Clang even uses an
external file for its command line arguments, kind of [1], despite not
doing any localization of strings).
I am mostly working on 3D stuff... (mostly a game, but also some 3D
tools, ...).
its "user facing" side is mostly the 3D renderer, sound mixing, and
user-input handling (mouse, keyboard actions, keyboard shortcuts, ...).
text isn't really a big part of the normal experience, nor much
information presented as natural-language text (there is a fair amount
more in terms of variables and formatted numerical output, but this
isn't really the same).
most of the code in the project, however, is internal infrastructural
code, most not really having much direct user interaction.
basically, it is a project which is slightly over 1 Mloc (1 million
lines of code). a few of the bigger chunks here are mostly stuff related
to my scripting language, and also the 3D renderer. together, they make
up a large percentage of the total codebase, followed roughly by the
"server end" in 3rd place (the server-end is what holds most of the
"gameplay logic", like physics code, weapons and items logic, enemy-AI
logic / behaviors, and so on...).
currently, there is very little in terms of a GUI (traditional GUI
elements are almost completely absent from the program).
there is an interactive console though, which mostly functions in a
manner vaguely similar to the Linux shell interface though (type
commands, see results). typically, commands are terse names, and don't
usually generate much printed output. these commands are implemented
in-program, and operate in terms of a program-local virtual-filesystem.
where relevant, commands have similar names and behaviors to their Linux
analogues (cd, ls, cat, pwd, ...). (there is little obvious reason
though why anyone would want to change these though, like 'cd' or 'ls'
should probably be fairly universal independent of language?...).
there is an in-program text-editor though, which provides an interface
partway between MS-Edit and Vim (cosmetically, it looks a little more
like MS-Edit, but handles user input in many ways a little more like
Vim, with ALT-';' switching to the command-entry prompt, ...).
some parts of the engine are controlled by "cvars" though, which
function in a manner vaguely similar to environment variables.
or, IOW, there is lots of stuff going on, and lots of stuff for the user
to interact with, just relatively little where textual feedback is
really called for (at least much beyond debug messages). (and,
presumably, normal users/players shouldn't normally be messing around in
the console anyways, apart from maybe to enter cheat-codes).
Even if you don't need to provide translated messages, there is benefit
to centralizing program messages in external files. Ensuring consistency
is one key benefit that I can think of.
could be, but it doesn't really tend to be a big use case.
most of what is printed, is usually an indication of where the message
is being printed from (function/method names and similar), and a terse
description of the event, and usually a few items giving the values of
relevant arguments or variables.
given most of this isn't really intended for end users, it doesn't
really make much sense for translation.
granted, a person could translate any voice-acted dialogue, which would
probably be a bigger use-case for translation I think, but at the
moment, there isn't a whole lot of this either (that is actually
relevant to gameplay).
even with language-specific strings, unless using magic numbers, a
string may still be needed to refer to them.
And a constant String is often used instead of copy-pasting the literal
around.
[1] The "kind of" is that this is turned into compiled code by a build
step.
could be, depends on whether the literal is one-off, or used more than
once...