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

Ideas on how to make translation tasks easier #4

Open
lukaszdaniel opened this issue Mar 24, 2016 · 2 comments
Open

Ideas on how to make translation tasks easier #4

lukaszdaniel opened this issue Mar 24, 2016 · 2 comments

Comments

@lukaszdaniel
Copy link

Hi there,

I got your message where you asked for opinions on what could be done in order to make translation tasks easier. I'd like to share my opinions concerning translatable messages based on my experience with R and its recommended packages.
What made it difficult for me to translate R* to polish language was as follows:

  1. Chopped messages like warning("there are", number, "elements"). In english language its not a big deal, but other languages may have different form depending on what the context is. So: Do not chop messages.
  2. Unclear messages like warning("didn't converge"). Again for languages other than english it may be difficult to keep one (global) form. So: (using my example) Always tell WHAT didn't converge.
  3. Semi-plural forms like warning("there are %d element(s)"). English has 1 plural form, some other languages have more than 1. So: Use ngettext(number, "single", "plural") even if "single" form will never occur. Or more general, use ngettext whenever you count something.
  4. More than one form of the same sentence like "there is 1 element" vs "there is one element", "not an 'matrix' object " vs "argument '%s' is not an object of class '%s'", and so on. So: Standardize messages where possible.

To sum up, from my point of view, it all comes down to the non-technical problem of localization-awareness among developers. Can't recall technical ones - sorry.

@lukaszdaniel
Copy link
Author

After some thoughts I have few ideas.
Give warning, when during creation of pot file you notice chopped messages, or '(s)' monsters (like: "element(s)"). Suggest ngettext, when you notice %d in a message (usually it is used for counting).

@leeper
Copy link
Member

leeper commented Mar 24, 2016

Great suggestions, thanks! Sounds like we could also make some
documentation showing examples of good and bad message constructions, in
addition to creating technical checks.
On Mar 24, 2016 3:00 PM, "Lukasz Daniel" [email protected] wrote:

After some thoughts I have few ideas.
Give warning, when during creation of pot file you notice chopped
messages, or '(s)' monsters (like: "element(s)"). Suggest ngettext, when
you notice %d in a message (usually it used for counting).


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#4 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants