Re: [Tuxpaint-i18n] question on tuxpaint translation [qx/QX/Oo/etc.]
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
From: Pere P. i C. <pe...@fo...> - 2010-04-12 21:50:24
|
El dg 11 de 04 de 2010 a les 10:44 -0700, en/na Bill Kendrick va escriure: > On Sun, Apr 11, 2010 at 06:19:54PM +0200, Iron Bishop wrote: > > hi, in the translation process I cant figure out how to translate these: > > > > 1) "<1>spare-1a" > > 2) qx > > 3) QX > > .. > > > > can you tell me where to find explanation or give me one? i already read the comments but cant understan. > > > > thx > > > > Hi Flavio. This is for a system that determines which > fonts should be ignored, and which should be given higher > 'score' (shown higher in the list of fonts) when using > the Text tool (and the new Label one). > > I'm Cc'ing the tuxpaint-i18n mailing list, in case anyone has > corrections or further commentary. (And also so that other > translators can be brought up to speed on this.) > > > You can translate "qx" and "QX" into strings in your > language for which characters in the font _must_ exist, > otherwise the font is 'blacklisted.' > > For most locales, there's not any reason to blacklist > a font, so those strings can be left alone > ('translated' to "qx" and "QX" is probably better than > just leaving them blank/untranslated in the PO file). > > > The other strings allow you to add weight to fonts > which include certain characters that your locale needs. > So, for example, you might translate "oO" to > "oOÃÃ" (adding 'i' and 'o' with acute accents at the end). > And you could translate the punctuation string in such > a way that the result includes "Â" and "Â" (guillemets / <<, >>). > > The "spare" ones are currently unused (wrapped in an "#ifdef 0 ... #endif" > block in the C source code), so can be safely ignored. > > I hope that helps! > Those checks will pass when all chars in the translated string are rendered and there are no duplicate renders, or will fail if there are any char not rendering or there are two chars rendering the same gliph, to cover the case of fonts who replaces lacking gliphs by squares or similar. Suposing a font that has only the abcde gliphs and that replaces lacking gliphs with squares, the string abcdf will pass the tests as the f will render as a square. To make it fail you need to cause two renders of lacking gliphs, like abcfg, f and g rendering to squares, they render the same gliph, causing the test fail. Also, if you know a pnemonic for the special chars in your language and it has two identical letters, it will cause the test to _always_ fail, say the string aa will _always_ fail. Hope this helps. Pere |