Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account

Advice/Best Practices With Language Translation For Rulebook Specific Jargon

1682204867
John D.
Pro
Sheet Author
I worked myself into a conundrum while weaving translation changes into a sheet I'm working on, specifically when I ran into words related to rulebook/game mechanics specific terms.  The specific case that got me thinking about this is there's an attribute for "size" in the Tri-Stat Core game system.  While this is a numerical value, each value has a label.  Such as, the default value is 0 which represents "medium" size.  The size above value is 1 which represents "large", and the size below is -1 which represents "small".  These values range from -10 to 10, and each value has its own unique label (e.g. mammoth, colossal, teeny, mote, etc.) My question is, should rulebook jargon like this also get translated?  I don't know if all the jargon would translate correctly or in a way that would make sense or be congruent with the spirit of the game system author's intent.  Also, would a player draw the correlation between the translated jargon on sheet with its analogue in the rulebook? Thoughts?  Experiences? Thanks in advance!
Hi John, I can speak about our methodology with regards to translating rules content on the Sheet Development team, and perhaps you can interpolate an answer that makes sense for you. In general, we try to provide translation strings for any non-user submitted content on the sheet, even those that are game specific, or toggled on in response to user feedback. So, for instance, when a character becomes encumbered on the 5e sheet, the text that appears there is able to be translated. The basic premise behind this is that we will never be able to correctly identify the correct choice for every language that might require a localized version, but that we can safely assume that those folks contributing translation strings will know what is best in their situation. If the translation is necessary or desired, they can translate it, and if it is not, they can leave it as is. Luckily, adding translation capability is pretty straight-forward, either with the various data-i18n attributes, or with the getTranslationByKey sheet worker. I hope this helps. If you have any clarifying questions, please do ask!
1682364927
John D.
Pro
Sheet Author
Thank you, Nic!  That makes sense and puts my troubled mind at ease. Agreed, adding translation capability is pretty straight-forward but much easier at the onset of sheet development.  ;) I appreciate your feedback!