Job Names use old localization naming scheme

[bjubes]

Expected behavior

Job.GetName() should return the new localization key such as furn_steel_wall. This is later parsed by the localization system to return "Steel Wall" for english

Actual behavior

the jobName is equal to furn_SteelWall which the localization system doesn't know what to do with.

Steps to reproduce the behavior

• place a wall (or any furniture), creating a build job.
• left click the sprite of the job.

you will get an option in the context menu like "Cancel furn_SteelWall"

[Geoffrotism]

I can address this in my #1580 Fix.

[Geoffrotism]

Actually, when delving into this I found it's way above what I can do. I localized this specific case, literally it localizes the name of build job for cancelling from the context menu. Localization seems to be something people didn't think about when creating different aspects.

[bjubes]

@Geoffrotism I did something similar in my pr #1587. This is how i discovered the issue, since the Name of a job isn't actually a valid localization string.

Localization seems to be something people didn't think about when creating different aspects.

Since working on localization I have tried to make sure there is no more hard coding names in PRs, but most of the damage is already done

[koosemose]

A related issue I've noticed while working on #1739 , the way job descriptions are set to be localized is by concatenating "job_build_" + type + "_desc", which means every furniture and everything that needs to be built would have to have a separate key, which seems cumbersome. I know the localization system can have keys with {N} in them to automatically use a parameter in place of the bracketed number, but with how it gets the description from jobs (and presumably names) it expects that to be the entire key.

Is there any way we can have the job just have something like Description = job_build_furniture_desc and Name = job_build_furniture and then the localization system get that + the furniture's (or whatever) appropriate localization code so that we don't need separate localization keys for the build jobs of every furniture, utility and whatever other jobs of basically the same type that can act on multiple different objects?

[bjubes]

what your suggesting seems feasable, just make a generic job_build_furniture_desc = build {0} in en_US and then pass the localization system job_build_furniture_desc and the furniture (I believe it will try to localize parameters passed so the furniture will be localized but if not thats an easy fix.) However, there may be some edge cases that need a separate localization string, and some of those edge cases may only be a certain language, but I think overall using a generic string with a parameter for the furniture name is the best solution.

[koosemose]

The problem is the point at which it is done, it is in the actual UnlocalizedDescription Property that it returns "job_build_" + type + "_desc". What makes it problematic is that not every job will need the same parameters, building jobs you'd use build {0} and pass the buildable's localization key, but a hauling job you'd want Hauling {0} and pass the inventory being hauled. Other jobs may want other things passed differently as well. I'm just not sure how exactly it can be done so that all job types are localized in a reasonable manner