It'd be cool to attach metadata to string literals that doesn't end up in the resulting string object. This metadata could be used by all sorts of tools, everything from localization to refactoring. In C, some localization libraries use macros for it, such as: #define LOCALIZE(s) s and it acts like an annotation, and then you do: printf("%s", get_localized(locale, LOCALIZE("This string gets extracted and used in language files"))); And I think Python could do better and have special string literals explicitly for this purpose. It could even be something with fstrings, like: f"{#localize}This string gets extracted and used in language files" Ofc, there's nothing preventing one from using something like f"{(lambda _:'')('localize')}This string gets extracted and used in language files" today, but I feel like having some sort of dedicated syntax for it would be an improvement.
On 2/2/2020 8:28 PM, Soni L. wrote:
It'd be cool to attach metadata to string literals that doesn't end up in the resulting string object. This metadata could be used by all sorts of tools, everything from localization to refactoring.
In C, some localization libraries use macros for it, such as:
#define LOCALIZE(s) s
and it acts like an annotation, and then you do:
printf("%s", get_localized(locale, LOCALIZE("This string gets extracted and used in language files")));
And I think Python could do better and have special string literals explicitly for this purpose.
It could even be something with fstrings, like: f"{#localize}This string gets extracted and used in language files"
Ofc, there's nothing preventing one from using something like f"{(lambda _:'')('localize')}This string gets extracted and used in language files" today, but I feel like having some sort of dedicated syntax for it would be an improvement.
You might want to look at PEP 501. Eric
On 2020-02-02 11:29 p.m., Eric V. Smith wrote:
On 2/2/2020 8:28 PM, Soni L. wrote:
It'd be cool to attach metadata to string literals that doesn't end up in the resulting string object. This metadata could be used by all sorts of tools, everything from localization to refactoring.
In C, some localization libraries use macros for it, such as:
#define LOCALIZE(s) s
and it acts like an annotation, and then you do:
printf("%s", get_localized(locale, LOCALIZE("This string gets extracted and used in language files")));
And I think Python could do better and have special string literals explicitly for this purpose.
It could even be something with fstrings, like: f"{#localize}This string gets extracted and used in language files"
Ofc, there's nothing preventing one from using something like f"{(lambda _:'')('localize')}This string gets extracted and used in language files" today, but I feel like having some sort of dedicated syntax for it would be an improvement.
You might want to look at PEP 501.
Eric
Oh. No, I want it to return plain strings. e.g. you should be able to replace an existing MY_STRING = "This string gets extracted and used in language files" with MY_STRING = [uhh idk what would go here tbh] and maintain full backwards-compatibility. It's for external tools to consume, not for python code to consume.
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GEBY52... Code of Conduct: http://python.org/psf/codeofconduct/
Why don't you define a LOCALIZE function (x → x) like in your C example? Le lun. 3 févr. 2020 à 13:01, Soni L. <fakedme+py@gmail.com> a écrit :
On 2020-02-02 11:29 p.m., Eric V. Smith wrote:
On 2/2/2020 8:28 PM, Soni L. wrote:
It'd be cool to attach metadata to string literals that doesn't end up in the resulting string object. This metadata could be used by all sorts of tools, everything from localization to refactoring.
In C, some localization libraries use macros for it, such as:
#define LOCALIZE(s) s
and it acts like an annotation, and then you do:
printf("%s", get_localized(locale, LOCALIZE("This string gets extracted and used in language files")));
And I think Python could do better and have special string literals explicitly for this purpose.
It could even be something with fstrings, like: f"{#localize}This string gets extracted and used in language files"
Ofc, there's nothing preventing one from using something like f"{(lambda _:'')('localize')}This string gets extracted and used in language files" today, but I feel like having some sort of dedicated syntax for it would be an improvement.
You might want to look at PEP 501.
Eric
Oh. No, I want it to return plain strings.
e.g. you should be able to replace an existing
MY_STRING = "This string gets extracted and used in language files"
with
MY_STRING = [uhh idk what would go here tbh]
and maintain full backwards-compatibility.
It's for external tools to consume, not for python code to consume.
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GEBY52... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HY6N3C... Code of Conduct: http://python.org/psf/codeofconduct/
-- Antoine Rozo
On 2020-02-03 03:55, Soni L. wrote:
On 2020-02-02 11:29 p.m., Eric V. Smith wrote:
On 2/2/2020 8:28 PM, Soni L. wrote:
It'd be cool to attach metadata to string literals that doesn't end up in the resulting string object. This metadata could be used by all sorts of tools, everything from localization to refactoring.
You might want to look at PEP 501.
Eric
Oh. No, I want it to return plain strings.
How about using annotations? >>> LocalizedString = str # etc >>> my_string: LocalizedString = "An important message." Perhaps _ is a more expected name however. -Mike
On 3 Feb 2020, at 01:28, Soni L. <fakedme+py@gmail.com> wrote:
It'd be cool to attach metadata to string literals that doesn't end up in the resulting string object. This metadata could be used by all sorts of tools, everything from localization to refactoring.
In C, some localization libraries use macros for it, such as:
#define LOCALIZE(s) s
and it acts like an annotation, and then you do:
printf("%s", get_localized(locale, LOCALIZE("This string gets extracted and used in language files")));
And I think Python could do better and have special string literals explicitly for this purpose.
It could even be something with fstrings, like: f"{#localize}This string gets extracted and used in language files"
Ofc, there's nothing preventing one from using something like f"{(lambda _:'')('localize')}This string gets extracted and used in language files" today, but I feel like having some sort of dedicated syntax for it would be an improvement.
(forgot to cc the list) If you use the stdlib gettext library then the default is to use the _() function for translations. print(_('Translate me')) The tooling knows how to extract the strings in _() and build a .pot files for use with translations software. I think the placing of _ into the builtin's is deprecated. You can define your own short names for the functions in gettext that you want to call. Then tells the tools to look for the names you use. The docs cover this. Barry
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OUUKHT... Code of Conduct: http://python.org/psf/codeofconduct/
participants (5)
-
Antoine Rozo -
Barry Scott -
Eric V. Smith -
Mike Miller -
Soni L.