Change:
<ins> require('dotenv').config({ path: `${__dirname}/../../.env` }); const { getFiles } = require('../../utils/files'); const { getStrings, changeHiddenStatus } = require('../../utils/strings'); // eslint-disable-next-line import/no-unresolved const core = require('@actions/core'); const filename = core.getInput('filename'); const stringContent = core.getInput('string-content'); const hideString = async (projectId, fileName, string) => { const fileResponse = await getFiles(projectId); const targetFile = fileResponse.find(el => el.path.endsWith(filename)); if (!targetFile) { core.setFailed(`${fileName} was not found.`); return; } const stringResponse = await getStrings({ projectId, fileId: targetFile.fileId }); const targetString = stringResponse.find(el => el.data.text === string); if (!targetString) { core.setFailed(`${string} was not found.`); return; } await changeHiddenStatus(projectId, targetString.data.id, true); console.log('string hidden!'); }; const projectId = process.env.CROWDIN_PROJECT_ID; hideString(projectId, filename, stringContent); </ins>

Discussion:
<!-- NOTE: If you're reporting a security issue, don't create a GitHub issue. Instead, email We will look into it immediately. --Affected page Your code Copy and paste the code from the editor that you used in between the back-ticks below: Expected behavior Text with the example code is not translatable - which is fine. However, the text lower is translatable and this will create confusion for end users on other languages. Screenshots Untrabslatable example: ! vs. Translatable output of the exmple: ! System (please complete the following information): Device: Laptop OS: Windows 10 Browser: chrome Version: 91.0.4472.77 Additional context Add any other context about the problem here.
I think this is expected behaviour. That is because its and example we would not translate it.
Sure... then the description of the output should not be translated either and right now it is.
I think The description should be translated. Which I understand it currently is. This gives the context of the example that follows. The example text line should NOT be translated because it's a literal output of the code. Which I understand it currently is not. It looks like we would want the current behaviour though I would wait for someone else to confirm.
I was just thinking under translation context: people looking at this page in other languages will see on the page: if you write a text like this (in English): ..... that code produces the output (for example in Romania ): Acesta este ul link către la care poți ajunge. I personally would be confused how English is rendered into Romanian by itself
I believe all the other languages are translating the example and instructions, so you are correct both should be translated.
the example in code can't be translated the example can't be translated, so if the result is translated it will never match in English it says Here's a link to for you to follow. where in Spanish it says Aquí hay un enlace a para que lo sigas. where the second line would be how the code above should appear it is translated in Chinese too, and I think we translated it also in Italian But it stands more correct to be kept in English as actual rapresentation of what the result of the code is
Thanks, that is what my initial thought was like I mentioned.

I think we should get this change in all languages and have a check to catch changes as a warning. can you guide us here?
Unfortunately our current workflow doesn't have a quick way to mark a specific string as non-translatable. I could probably put something together, but IMHO it might be worth re-wording the challenge instead.
Hmm, did Crowdin not have a way to manually mark it non-translatable? I might be mistaken though.
We can do that, yes - we would need to revert the translations for the languages which have translated it. However, I believe that hidden state is lost every time the file is re-uploaded.
Hmm, I see. Thanks for clarifying all this. I am glad that I double-checked with you. Do you mind sending a quick support request to Crowdin, seeking advice?
Sure thing - will add that to the list today and CC you :)
Okay I slept on this, and decided to see if there was a way to automate this process. PR coming shortly.
now that this has been merged do we need to do anything over on Crowdin or in our codebase to reset the strings?
Thanks for the reminder I have gone through and cleared the existing translations for this string - it should come down in English for all languages going forward.
Awesome, thanks for taking care of it.