DMagic

Links to the actual content that needs translating should really be provided if people want help. When asking for someone to help in translating your files they really shouldn't have to dig through a GitHub repo or download the mod and search through the folders to find what needs translating. Going further and providing an in-depth guide for how to translate the text like HebaruSan does is also fine, but a direct link to the file or folder with the text would really be helpful. Also keep in mind that, while you can name the localization tags anything, it might be best to keep the "#autoLOC_mod_identifier" format used by Squad (regardless of why it was used in the first place) because it helps to instantly identify a line as one used for localization.

I've been using my own tooltip implementation (it's rather pitiful that Unity hasn't come up with a native tooltip solution) based on a modified version of one found in the Unity UI extensions. I ran into the same issues with trying to deal with the tooltip prefab and decided to make my own, as it allows for more flexibility. It obviously doesn't help much if you aren't using a full Unity-editor UI, but it works for me. This script is attached to the Tooltip prefab that you make in Unity (it mostly controls positioning the tooltip). And this script is attached to whatever you want a tooltip for (it mostly controls the mouseEnter and mouseExit events to spawn the tooltip). If you want to get a KSP tooltip prefab it's best to try to find another prefab that has it, rather than waiting for some other window to load. For instance, if you can find the KerbalPortrait prefab (which would require finding the KerbalPortraitGallery prefab...). That way you aren't reliant on something else being loaded, since some things might not be loaded in different game types, or may be effected by mods. This is what I've been doing with my not-yet-released deltaV mod to get some of the Contract App sprites and UI elements. If you can't find a prefab somewhere, you can always just resort to checking the Resources class; see here. Resources.FindObjectsOfTypeAll is different from GameObject.FindObjectsOfType, as the latter only looks for currently active objects, while the former searches through all of the loaded Resources (eg. it would work in the Main Menu, or in a sandbox game where the Contracts App is never actually loaded). As for getting GameObjects, it doesn't matter if one is exposed or not, you can figure out the object hierarchy with Debug Stuff and then use GetComponent or one of its variants to find what you need.

@Moskit You can't. Most of the UI text is carefully created to fit within a certain size. Translating that text would in many cases break that, so I'm not going to bother.

Now that 1.3 is out we can start populating this thread with mods that support localization and mods that include translations. If mod authors could post in here with their mods that support localization that would help. Some information should be included along with the mod name and link. This includes any language translations already provided, the amount of text that needs translating (both line and word count would be best), and the languages that need translations. Some updated links for localization information: One thing of note that I didn't see explicitly mentioned, since the CelestialBody.displayName returns the name with the gender tags (Kerbin^N instead of Kerbin) you will need to format the string before displaying it. If this is to be used as part of a longer string loaded from a config file then it shouldn't be a problem, but if you are using the name by itself, in a list of celestial bodies for instance, then you need to make sure to process it first. Rather than making a localization string that consists of <<1>> in a config file, I've just been using a string extension: public static string LocalizeBodyName(this string input) { return Localizer.Format("<<1>>", input); } string text = body.displayName.LocalizeBodyName();

Version 17.6 is out; get it on GitHub. It is updated for KSP 1.3 and has many localization related changes. These include support for localizing the part descriptions, science results and most of the part action window text. The existing help tooltips, window tooltips, and popup warnings now use the stock system for localization. There are also a number of fixes and tweaks since the last version. The background scanning toggles should work now. The anomaly icons align the circle at the bottom of the question mark directly over the anomaly, Celestial body lists are now ordered by distance to the sun and moons are grouped with their parent planet, TextMesh Pro is used for all input fields, a science point exploit has been fixed, and a new part module is used to define science experiments. This new module allows for better handling of combined parts where you might want multiple experiments on the same scanner. Native support for localized celestial body names, resource names, and biome names is also included. Russian translations for the tooltips and warning have been provided by Ser. @Ser

Can I get this localization thread moved back to the Add-On Discussions forum? It is intended to be a thread for keeping track of which mods offer or support localization, in addition to helping mod authors with adding such support.

@Cetera SCANsat loads and unloads bodies once per game session when it's building its initial database. Each body takes about 10 seconds to load, so loading all of the planets can take some time (the loading is slow enough that it shouldn't have any effect). When Kopernicus is installed it has to force each body to load before it can read that body's terrain data, after it finishes it unloads the body. From the logs that's what seems to be happening, each Kopernicus unload message is followed a by a "Height map complete" message. After the database is built the only time SCANsat should force a body to load is if you open the big map and display a planet different from the current body. This block looks like it occurs in the SpaceCenter scene, nothing else seems to be going on, because processing this many planets would take a while: Another block from the flight scene I think: As long as this doesn't continue happening it is working as it should. The performance effect of this processing should be considerably less than 1/10th of what is required to build a reasonably sized SCANsat big map. So if you can use the other SCANsat functions then this is unlikely to be causing such a serious drop.

@ioresult There are a few bugs with the SIGINT and soil moisture antennas in the current version. I'll update with fixes (and the ability to turn off the transmitter function) whenever 1.3 is released.

@Aelfhe1m The differences in labels are intended since the zoom map has the potential to be much smaller and there are certain circumstances where the text might run over. The Orbital Science anomaly scanner doesn't work with the ground stations since they are technically not the same thing as the regular anomalies. It will need to be updated to fix that.

@msnbcorp I'm not seeing the RT error in that log. The only thing of note I see is that you might have 2 copies of the Kopernicus.OnDemand plugin in your GameData/Kopernicus/plugins folder. That seems like it might be a bad thing, and the Kopernicus on demand loader is the only point where SCANsat and RT might overlap, since SCANsat forces planets to be loaded at certain points, and unloads them when it's finished. @tomf That might be a CC problem. @Dewar I'll see about adding those 2 resources for the next update.

@davidpsummers It would appear that you don't have the EVA Transfer plugin in your KSP/GameData/EVATransfer folder. If you don't have the plugin it won't work, delete it and reinstall, making sure that the EVATransfer.dll file is present.

@psamathe See the KSPedia entry or the SCANsat wiki (both are a little out of date, but are mostly still accurate). That is expected behavior dependent on your resource scan settings.

@Yargnit Modifying them to make the base point movable might be possible, so that you could re-position either end. But allowing for the strut (or fuel pipe) start point to be placed on EVA is way outside the scope of this mod. I don't want to get into spawning new parts, setting joints, etc... And it would require some kind of inventory system, no matter how simple, otherwise you would just be able to infinitely place new struts. Both mods are compatible with KIS, so they can be placed on EVA using that. @davidpsummers It looks like some kind of bug when the fuel pipe is first initialized or clicked on. I can't say any more without seeing the full log files.

I think the simplest solution, for now, would be to distribute your mod with all of the translated KSPedia assetbundles (with the language as a suffix on the file name), but only put the .ksp file extension on the primary language. Then you can instruct users to change the file extension if they want a different language. It's not ideal, but then I imagine there won't be more than a handful of mods that actually go to the trouble of making KSPedia translations. KSP's asset loader will ignore bundles without a file extension, so the others will just be ignored.

@Gordon Dry The Toolbar error looks like the least of your problems (that error is common when something with a UI is displayed immediately upon a scene change; if it only happens once it is harmless). Your log file is absolutely filled with errors from Real Fuels, Tweak Scale, and RPM. It's possible that another maneuver editing mod might conflict with this, I'll have to check.

@Voodoo8648 The change log is in the first post. It is very long.

@Morse I think you just need to make different KSPedia entries for each language. They would probably have to be offered as a different or separate download package to avoid having all languages show up.

The folders outside of the KSP/GameData folder (these are Kerbal Space Program/Parts, /Internals, etc..., they are all empty for a reason) are obsolete and no new mods should be placed in them. For some reason they have been left in place from the time, several years ago, when they were actually used. But they should never be used for mods today (if you can find a 3 year old mod that still works on the current version of KSP I would love to see it). Many mods are absolutely dependent on specific files being in specific locations, moving folders around is guaranteed to break those mods. Anecdotal evidence to the contrary doesn't mean anything other than that you have found a few mods that don't break when their folders or moved, or that some of them are broken, but you just aren't aware of it. Also, anyone looking for KSP mods would be better off searching through SpaceDock, it has considerably more mods, and more of them are up to date (SpaceDock only started about 1 year ago, so basically anything there is compatible with KSP 1.0 - 1.2.2, whereas Curse has had more time to acquire dead mods).

One of the much alluded to changes has taken place in the Localization methods. The Class name has been changed from Localization to Localizer. So if you have been doing any pre-release work just do a find a replace for Localization.Format to Localizer.Format and it should work fine. There has a also been a bug fix to avoid NRE's if you do something silly like passing a null string into the Format method.

@Smarti The stock difficulty options menu. It can be found in-game by going to the Settings screen and opening the Difficulty options at the very top of the settings menu.

I'm not sure how much value there would be in disabling the readouts for individual stages in the editor, I'm sure that there are valid reasons for it, but just maybe not enough to make the effort to implement it . It adds a little bit of UI clutter, but the windows don't intercept mouse clicks, and you can adjust the transparency of the background so that it's little more than floating text. There is also the issue that the stage headers already have a mouse click handler for when you want to pick up a stage and drag it. It's probably still possible to differentiate short clicks from a click-and-drag, but it could be finicky in practice. For now you can right-click on the toolbar button to toggle the readouts or use a toggle button in the settings part of the control window. If the same readouts were applied to the flight scene then I could see why it would be valuable to only display information for certain stages, or limit the display to the active stage. Though for me, at least, a deltaV readout in flight is a very different thing than a readout in the editor. It's the same information, but it serves a different role in the two scenes.

@Sigma88 For the scanners you just use MM patches to adjust the scanner min, best and max height by whatever multiplier the system uses (or some other value if you want to fine-tune the adjustments). You'll also need to adjust the terrain height data used for drawing the maps. Those values can be found in the SCANcolors.cfg file in the SCANsat/Resources folder: SCAN_Color_Config { SCANsat_Altimetry { Item { name = Kerbin maxHeightMultiplier = 1 minHeightMultiplier = 1 clampHeightMultiplier = 1 } } } If the planet does have an entry in that file then I don't think it matters, since SCANsat attempts to figure out the min and max terrain heights for any unknown planets.

Apparently this managed to slide by without notice. It would seem the Text Mesh Pro is now free and will eventually be integrated into Unity: You can download it from the Asset Store for free, so I guess my tedious workarounds for not having access to TMP in Unity are no longer necessary.

I like the idea of providing a Delta V readout in the editor. It simplifies some issues and allows you to work around problems with weird designs by measuring dV separately for the different components of a vessel, like an Apollo-type orbiter and moon lander situation. I also like keeping it simple and not cluttering up the UI with another window full of buttons and labels. I like the idea so much I went ahead and did it.

@Rodger That's a good idea. The simplest way to handle it would be a to re-order the list so that the current planet is always at the top. I need to re-order the list anyway to make it show the planets in order from inner to outer and to group moons together with their parent planet. A separate button might also work, too.