fix: add translateble false to generated android strings

[emartynov]

#893

Description of changes:

Add translatable="false" attribute to the generated strings. I assume it is default and only one correct use of these strings.

Android documentation is here http://tools.android.com/recent/non-translatablestrings

It would be also great to add test for it here https://github.com/amzn/style-dictionary/blob/main/__tests__/formats/androidResources.test.js

[emartynov]

This probably will be never merged

[chazzmoney]

Two quick questions:

1. Is there potential for a situation where the string should not have this attribute? Like somehow someone uses SD for an actual message to be used for ux display to the user?
2. Can you add the test?

I think if we had the test and the answer to the question, it would make this actionable.

[emartynov]

For the first question, I can not say for sure. Is there an option to make it configurable?
I will try to write tests. However, my typescript knowledge is limited. I will try to mimic some existing tests.

[chazzmoney]

I think it is likely that someone is using SD to have multi-platform translatable strings, including strings on Android. To avoid breaking any users who might be using SD in this way, this functionality should be enabled by configuration.

[chazzmoney]

config options are passed in to this template via the function here:

style-dictionary/lib/common/formats.js

Lines 538 to 543 in b0a89ca

	'android/resources': function({dictionary, options, file}) {
	const template = _template(
	fs.readFileSync(__dirname + '/templates/android/resources.template')
	);
	return template({dictionary, file, options, fileHeader});
	},

[chazzmoney]

Its maybe a weird moment; we have lots of config but not much (I think none?) config specific to a platform / output format. This is the documentation for config:

https://github.com/amzn/style-dictionary/blob/b0a89ca766af6891b0d731a047820693d65c9bf1/docs/config.md

We have config for platforms and for individual files, but we don't have any info about documenting options for platform specific configurations. We will have to add something I think.