Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow partial string replacement in package.json/package.nls.json, to ease translations of strings containing markdown #125774

Open
Colengms opened this issue Jun 8, 2021 · 6 comments
Assignees
Labels
feature-request Request for new features or functionality l10n-platform Localization platform issues (not wrong translations)
Milestone

Comments

@Colengms
Copy link
Contributor

Colengms commented Jun 8, 2021

Currently, various strings in package.json can be replaced with keys that refer to strings in package.nls.json. This enables localization of those strings (using vscode-nls and vscode-nls-dev, which generates package.*.nls.json for each language translation.)

Currently, only whole string replacement is supported. For example:

In package.json:
"description": "%key%"

In package.nls.json:
"key": "description string"

... works as expected. However using the following in package.json does not:

"description": "blah %key% blah"

... The resulting string is: blah %key% blah.

This is a request to support this scenario, and resolve this string as blah description string blah.

We have some strings that contain markdown. (i.e. strings passed to markdownDescription properties). However, our localization team is not necessary savvy with markdown. vscode-nls-dev has been updated to allow hints/comments to be specified in package.nls.json. However, indicating that a string contain markdown does not appear to have been sufficient to educate our localization team to avoid breaking the markdown syntax.

This is a request to enable localization of markdown strings without corrupting the markdown, by allowing us to expose for localization only the portions of the strings that do not contain markdown. This seems a relatively simple fix, whereas having translators become proficient in markdown is not as simple.

@Colengms
Copy link
Contributor Author

Colengms commented Jun 8, 2021

The specific solution I suggested may not be the best. Generally, translators need to see a full sentence to localize it properly. Perhaps there could be some sort of syntax to allow string literals to be added to localized strings?

Perhaps:
In package.json:

"description": "%key%",
"descriptionVariables": [ "Windows", "http://www.microsoft.com" ]

And in package.nls.json:

"key": "Use {0}.  Visit {1}"

Though, one issue we have is that translators have been adding a space between the "]" and "(" in markdown links. However, we want translators to be able to localize the title part of the markdown link.

Perhaps:
In package.json:

"description": "%key%",
"descriptionVariables": [ "Windows", "[%key2%](http://www.microsoft.com)" ]

And in package.nls.json:

"key": "Use {0}.  Visit {1}"
"key2": "Microsoft's web site"

@dbaeumer
Copy link
Member

dbaeumer commented Jun 9, 2021

We should support this the same way as we support place holders in the nls.localize call. So place holders should be denoted using {} since translators are aware of not touching those.

@dbaeumer dbaeumer added the feature-request Request for new features or functionality label Jun 9, 2021
@dbaeumer dbaeumer added this to the On Deck milestone Jun 9, 2021
@GitMensch
Copy link
Contributor

There were "pings to the loc team" by @sean-mcmanus and references to this issue - is it still open / "on deck"?

@sean-mcmanus
Copy link
Contributor

@GitMensch I'm not sure what "pings" you're referring to. Our team is still hitting problems in which the translators are breaking our markdown strings on a widespread basis, leading to like 50+ separate loc bugs having to be filed. So we'd like to be able to use {} replacements.

@dbaeumer
Copy link
Member

Adding @TylerLeonhardt since he know owns translation.

@TylerLeonhardt I can assist with this if necessary.

@TylerLeonhardt
Copy link
Member

Within Microsoft OneLoc, you can add a comment: "{Locked='string that should not be mangled'}" and whatever is in there will not be touched.

So we do this: "{Locked='](command:foo)'}" or "{Locked='](https://microsoft.com)'}" notice the ]( in the beginning of the locked string... this ensures that the [] part and the () part of a markdown link are not mangled.

With that said, I do think there is room for improvement in the tooling space here..... I'm just not sure which direction to take since this magical locked syntax is likely Microsoft OneLoc specific.

@TylerLeonhardt TylerLeonhardt added the l10n-platform Localization platform issues (not wrong translations) label Dec 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality l10n-platform Localization platform issues (not wrong translations)
Projects
None yet
Development

No branches or pull requests

6 participants