The Northern Smurfs called a certain object a “bottle smurfer”, while the Southern Smurfs called it a “smurf opener”.
Language customization is subtly different from language translation but both share similar localization processes, using the same tools.
( https://codex.wordpress.org/Localizing_WordPress & https://codex.wordpress.org/Translating_WordPress. Google for more)
Of course, as Lance accurately stated, using dedicated software is overkill if your intention is to change a small set of frequently used words site-wide (turning “groups” into “teams”, “members” into “players” and so on).
In which case I’d go for the “slugs” method, as suggested by Andy Peatling, rather than tinker with the language files.
As always, scale matters.
If you are interested in managing one or more custom language versions, or if you find yourself willing to change more stuff as it comes, I strongly advise you to consider the software option.
It’s a personal investment which requires you to do your homework and learn to organize your projects accordingly but the learning curve isn’t that steep, and it will guarantee you less white hair in the long run.
PoEdit is a good choice, giving you the full benefit of a precious asset: translation memory.
Once installed on your PC, it creates and maintains databases for each translation project – its original purpose. A feature that can be put to good use for language customization.
Its rather straightforward user interface lets you focus on the language changes you want to make, with a built in “search” feature to locate words or expressions.
There is no built in “find & replace” feature as software translation is primarily based on strings and not single word occurrences, which can be located in different strings with different contextual meanings.
If you really want to batch-replace words, you can achieve this using a text editor like Notepad++. Proceed with extreme caution, though: unexpected replacements using this method are frequent, that you can’t always undo except by hand, which defeats the purpose of the whole process.
Since language files are usually modified with each new release (added strings, modified strings, different string locations…), you’re also better off handling language file updates that way, keeping the language customization logic independent from the file itself, in PoEdit’s TM (translation memory) safe at home on your PC.
When upgrading BP, it will spare you tedious language files comparison and copy-paste hell in a river of strings, and will do the job with more accuracy.
A single mistake in a modified language file can generate cryptic errors which you don’t want to start tracking and debugging in 3,000 + strings distributed in multiple language files.
PoEdit gives you the ability to manage multiple language files using a single TM database (or as many as you wish).
This is especially useful when you know that the number of language files to be handled gets larger as your platform grows (plugins, themes and templates sometimes have their own – and should).
Using PoEdit will give you the required semantic homogeneity among all language files belonging to the same project, seamlessly.
This is where translators make significant productivity gains. And so can you.
What is more, the software approach scales nicely:
If you want to leverage your community’s knowledge for language customization – Klingon, Smurf, slang, professional jargon, secret dialect, whatever… – you may want to install Pootle
( http://translate.sourceforge.net/wiki/ ), an open source collaborative translation platform that does the same as PoEdit, on your server, and upload the languages files for collective customization – the scenario is yours.
)
