Judging by a screenshot I saw of it, the fonts used for that contracker thing in TF2 are a total mess, they appear to be missing all accented fonts and not even the fallback font is used instead of most of them, there are just spaces where non-English characters should be.

On a related note, were the other fonts used by the game ever fixed in terms of display/availability of non-English fonts, or are they still as broken as they always have been ever since release?

Hmm... I see absolutely no reason for that to be an image. It contains nothing but simple text, with the monitor on the right hand side being a separate image, so not even that's the reason. So that image with the text should be simply replaced with a div or other positionable element contaning actual, localizable text.

Since, as far as I know, tags can be defined by the developers for their products and also freely added by community members, it's unfeasible to localize them as they are not a fixed set in some static database which can simply be mapped 1:1 to a localized string set.

AFAIK XCOM2 supports community/fanmade localization through its Steam Workshop.

LogicBots has built in support for creating language file templates in English and uploading the translated version to its Workshop.

Sol 0: Mars Colonization can be localized via built in tools and/or in its Workshop (not sure how this one works, but I know it's possible).

Having something translated line by line by in a random order, by a bunch of random people will be just a horrible, inconsistent mess.

Ideally, a single person should do the entire translation, as that's the only way to ensure continuity and consistent use of expressions, wording, writng style etc.

Or, in cases where the entire text base can be split into clearly separated areas where one person working on one area doesn't have to know antyhing about how another person translated things in another such separate area, a few translators who have experience in working together collaborating and actively using a constantly updated glossary and other shared information may result in acceptable quality.

There is no "one particular program" to do it. It's nowhere as simple as that.

First off, as far as I know, you (as in, the player who wants to use unofficial mods such as localization packs) need a modified console OS (maybe even hardware, not sure about that) to be able to modify consle games, which is against the TOS/EULA/whatever you have for consoles and can get you banned from the online services of the given console type.

Then, each game has its own internal data format per engine and implementation used by the developers. You need tools specifically made for the given game to disassemble the data files, extract the files or binary data ranges that contain the localzation related parts of the game data, then convert it (usually with custom tools you'll have to write yourself) into something you can work with as text.

And finally, once you're done with the translation part, you need to convert the translated text back into the data structure used by the game (again, with a custom tool you made) and either replace the related original files with the modified ones if possible, or write/use a custom byte patcher which can modify the original files on the user's console by injecting/replacing the original localization data with what you made.

Oh, yes, please, an option to restrict search only to the English or the translated side could indeed be very useful for certain cases, even if not too often needed.

In its current implementation it has become next to useless, thanks to people mistaking it for a dictionary and adding literally every word there is to it.

Only moderators should be able to up/down vote (or even suggest additions to begin with), and there also should be a moderator only maintenance feature where the removal of unnecessary words can be initiated: 3 upvotes gets it deleted, 3 down votes puts it on a cooldown of a reasonable period (1-2 weeks?) before a new removal vote can be started.

Have you actually worked with "native" UE3 localization files? Sounds like you haven't, otherwise you'd know how much of an awful mess that is. It's not a simple list of "key:value" pairs like what Source is using, there are several "subformats", each of which need to be structured (and parsed) differently, and they can contain a lot of additional data that must not be localized but still has to be preserved during the process. With a lot of work, it can be programatically converted to the Source format, but it's not as straightforward as you suggest; it requires a dedicated, rather complex converter tool, and I'm guessing something like that has been created for KF2.

Since game engines in general use their own localization frameworks (if they have one at all, and not rely on somethign the developers have created specifically for that game), each requires its own specific converter at least on a per engine, but more often on a per game basis. And instead of "in-place" converting from a Source format intermediary to produce whatever file the given game is using (assuming it is possible at all, which in most case isn't as the required files are in a VFS or other package which would have to be delta-patched at specific locations to change the content), it makes more sense to convert the text data to a common "workfile" format in a controlled manner once, then once translated, export it back to the game's native format for distribution.

Not to further derail another thread intended for a different purpose, I decided to open a new one to explain and discuss what's wrong with the "sentence builder" templates from a localization standpoint, or rather, why they are impossible to localize to certain languages in the form they are currently implemented.

Let's consider the following example strings:

SomeApp_owned_vehicles - "%s1 has a %s2."
SomeApp_to_work - "%s1 goes to work by %s2."
SomeApp_John - "John"
SomeApp_Jane - "Jane"
SomeApp_car - "car"
SomeApp_bike - "bicycle"

This can dinamically produce different sentences, like:

"John has a bicycle." or
"Jane goes to work by car."

In English, the names of the two person can be used "as is" in either of the two templates, so you only need one instance of each.

However, in an agglutinative language, like Hungarian, this can't be made to work, since we need (or do not need) to attach specific, different suffixes to each of these names:

For the first template, "John" has to become "Johnnak" where "nak" is a kind of posessive suffix indicating that the root is in possession of something, but "Jane" will become "Jane-nek", where "nek" is the other variant of the same suffix (we have two variants of most suffixes), and this time a dash is also needed because of another rule regarding attaching suffixes in certain cases. This means that the suffix cannot be placed into the template itself since it has to be either "nak" or "nek" (or even "-nak" or "-nek" for the "dash-exception") depending on which name is used, thus it would have to be added to the name strings themselves.

However, for the second template, both "John" and "Jane" needs to remain as is, since in this sentence they do not attract any suffixes.

So, we cannot add the suffixes neither to the templates, since they depend on what will be in the first variable, nor to the names themselves, since the second template requires the names without any suffix.

The only solution to this is to have two sets of name strings for the two templates, even if they will be the same in English.

And the same goes for the possible contents of the second variable:

In English, "car" and "bicycle" will fit into either of the two templates "as is".

In Hungarian, for the first sentence they will become "autója" ("car -> "autó" + "ja", which is another posessive kind of suffix indicating that the root is the possession of someone) and "biciklije" ("bicycle" -> "bicikli" + "je", again, the other variant of this suffix); again, they attract different suffixes so it can't be added to the template itself.

For the second sentence, they become "autóval" ("car -> "autó" + "val", which is basically the equivalent of the English "by", only in the form of a suffix) and "biciklivel" ("bicycle" -> "bicikli" + "vel", again, the other variant of this suffix), and since these words attract a different suffix for this template than they do for the first one, the suffix cannot be added to the strings either.

The only solution, again, is to have two sets of vehicle strings, even if they will be the same in English.

So this is what would be needed:

SomeApp_has_a_vehicle - "%vehicle_owner% has a %owned_vehicle%."
SomeApp_has_a_vehicle_vehicle_owner_John - "John"
SomeApp_has_a_vehicle_vehicle_owner_Jane - "Jane"
SomeApp_has_a_vehicle_owned_vehicle_car - "car"
SomeApp_has_a_vehicle_owned_vehicle_bicycle - "bicycle"
SomeApp_goes_to_work_by - "%travelling_person% goes to work by %used_vehicle%."
SomeApp_goes_to_work_by_travelling_person_John - "John"
SomeApp_goes_to_work_by_travelling_person_Jane - "Jane"
SomeApp_goes_to_work_by_used_vehicle_car - "car"
SomeApp_goes_to_work_by_used_vehicle_bicycle - "bicycle"

And this is what it would look like in Hungarian, and would be capable of producing correct sentences:

SomeApp_has_a_vehicle - "%vehicle_owner% van egy %owned_vehicle%."
SomeApp_has_a_vehicle_vehicle_owner_John - "Johnnak"
SomeApp_has_a_vehicle_vehicle_owner_Jane - "Jane-nek"
SomeApp_has_a_vehicle_owned_vehicle_car - "autója"
SomeApp_has_a_vehicle_owned_vehicle_bicycle - "biciklije"
SomeApp_goes_to_work_by - "%travelling_person% %used_vehicle% jár munkába."
SomeApp_goes_to_work_by_travelling_person_John - "John"
SomeApp_goes_to_work_by_travelling_person_Jane - "Jane"
SomeApp_goes_to_work_by_used_vehicle_car - "autóval"
SomeApp_goes_to_work_by_used_vehicle_bicycle - "biciklivel"

Also, please note the variable notation in the templates, and how the names of the component strings reflect which template do they belong to, and which variable will they be put into. Using a notation system like this would go a long way to help identifying which strings belong to which sentence template, and in which variable are they used within that template.

-----

So, to try to sum up what would be needed to make most of these templates properly localizable to agglutinative languages:

- Each template has to have its own dedicated set of substrings for each variable.

- Substrings belonging to a specific variable of a specific template must not be used for anything else than for the one template and variable they were created for.

- The relation between the template and all of its substring sets, as well as the members of each substring set need to be marked clearly and explicitly, in a way that allows searching for all substrings belonging to a specific template, and all substrings belonging to each specific variable within a specific template.