Thread: [Tuxpaint-i18n] gettext()ification of the website
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
From: Bill K. <nb...@so...> - 2008-10-29 08:04:34
|
I've begun the long, tedious gettext()ification of the Tux Paint website. I'm loathe to try and copy over people's old translations from the various "{xyz}/trans/{locale}.php3" files, since they're often very, very out of date. Not knowing any of these languages, and knowing nothing of their encoding, it's probably best if I DIDN'T try to do it, regardless. A new 'tuxpaint-website.pot' is being constructed (based on the 'gettext()' wrappers found in the PHP files). Core content will move from "{xyz}/trans/en.php3" and just site directly in "{xyz}/index.php3", where it belongs... but wrapped in "<?=gettext(...)?>". I'm doing my best to reduce the amount of HTML found in the msgstr, but in some cases it's nice for the site to not say things like "you'll enjoy Tux Paint". (Notice the line break?) And sometimes <strong> and <a href> links are nice to have, and it will be hard to separate those from the actual text, without ending up with very. Short. Segments. In the POT file. :) Wish me luck, and suggestions welcome. So far I've done some bits from the front page, and the sidebar. I used Google to translate the first paragraph of the front page, which you can see here: http://tuxpaint.org/?lang=es_ES Yay. Finally. :) -- -bill! "Tux Paint" - free children's drawing software for Windows / Mac OS X / Linux! Download it today! http://www.tuxpaint.org/ |
From: Karl O. H. <ka...@hu...> - 2008-10-29 08:39:51
|
Bill Kendrick skreiv: > And sometimes <strong> and <a href> links are nice to have, and it will be > hard to separate those from the actual text, without ending up with very. > Short. Segments. In the POT file. :) Never break up sentences. And actually, it's best to use complete paragraphs as strings, not individually sentences. And remember to use the '--previous' option in msgmerge when updating the files (see the scripts used for tuxpaint and tuxpaint-stamps). Also note that there are tons of invalid HTML on the pages. Use http://validator.w3.org/ to see the errors. They're usually very easy to fix. -- Karl Ove Hufthammer |
From: Bill K. <nb...@so...> - 2008-10-29 20:23:18
|
On Wed, Oct 29, 2008 at 09:39:46AM +0100, Karl Ove Hufthammer wrote: > Bill Kendrick skreiv: > > > And sometimes <strong> and <a href> links are nice to have, and it will be > > hard to separate those from the actual text, without ending up with very. > > Short. Segments. In the POT file. :) > > Never break up sentences. And actually, it's best to use complete > paragraphs as strings, not individually sentences. Ah, good point. There are a few places where I need to use printf() or something to make some dynamic sentences translatable. > And remember to use the '--previous' option in msgmerge when updating the > files (see the scripts used for tuxpaint and tuxpaint-stamps). Ok, thanks. > Also note that there are tons of invalid HTML on the pages. Use > http://validator.w3.org/ to see the errors. They're usually very easy to > fix. Yeah. I'm a little old-school and sloppy. -- -bill! "Tux Paint" - free children's drawing software for Windows / Mac OS X / Linux! Download it today! http://www.tuxpaint.org/ |
From: F W. <fr...@tr...> - 2008-10-29 10:53:17
|
On Wo, 2008-10-29 at 01:04 -0700, Bill Kendrick wrote: > I've begun the long, tedious gettext()ification of the Tux Paint > website. ... Hallo Bill Is the POT file available for review? > Wish me luck, and suggestions welcome. So far I've done some bits from the > front page, and the sidebar. I used Google to translate the first paragraph > of the front page, which you can see here: > > http://tuxpaint.org/?lang=es_ES > > Yay. Finally. :) Congratulations! Can I recommend that you look at podebug from the Translate Toolkit? http://translate.sourceforge.net/wiki/toolkit/podebug This will make it easy for you to test that you have everything marked for translation, and there is also a mode that helps you test handling of Unicode. Keep well Friedel -- Recently on my blog: http://translate.org.za/blogs/friedel/en/content/its-easyer-with-kulula |
From: Bill K. <nb...@so...> - 2008-10-29 20:25:19
|
On Wed, Oct 29, 2008 at 12:52:59PM +0200, F Wolff wrote: > On Wo, 2008-10-29 at 01:04 -0700, Bill Kendrick wrote: > > I've begun the long, tedious gettext()ification of the Tux Paint > > website. > > ... > > Hallo Bill > > Is the POT file available for review? It's here: http://www.tuxpaint.org/help/po/ but... I'm FAR from done, so don't jump in and translate things yet, especially since while I'm doing this, I may clean up some of the original English strings. <snip> > Congratulations! Thanks. I wish I had done this from the onset. :) > Can I recommend that you look at podebug from the Translate Toolkit? > http://translate.sourceforge.net/wiki/toolkit/podebugp > > This will make it easy for you to test that you have everything marked > for translation, and there is also a mode that helps you test handling > of Unicode. Thanks, I'll take a look soon, hopefully. Lots and lots to do! -bill! |
From: Karl O. H. <ka...@hu...> - 2008-11-09 14:24:11
|
Torsdag 30. oktober 2008 skreiv F Wolff: >* XML entities make things hard to read. If we could use the literal >characters and have it converted for us in the code, that would make >things much nicer to read, translate and review. I understand why the >non-breaking space is desirable in many cases, but something like >"BeOS and Haiku" is hard to read, and translators might not be >familiar with the issue at hand. I don’t agree. should stay. We really should be able to expect translators to have som rudimentary knowledge on HTML when translating HTML. >* computer’s - I'm assuming this is an apostrophe. Please just >use an apostrophe and encode the page as UTF-8 or whatever you like. This I agree with. If you have trouble entering the apostroph, just modify your keyboard layout to get easy access to it. -- Karl Ove Hufthammer |
From: F W. <fr...@tr...> - 2008-10-30 10:34:20
|
On Wo, 2008-10-29 at 13:25 -0700, Bill Kendrick wrote: > On Wed, Oct 29, 2008 at 12:52:59PM +0200, F Wolff wrote: > > On Wo, 2008-10-29 at 01:04 -0700, Bill Kendrick wrote: > > > I've begun the long, tedious gettext()ification of the Tux Paint > > > website. > > > > ... > > > > Hallo Bill > > > > Is the POT file available for review? > > It's here: http://www.tuxpaint.org/help/po/ > > but... I'm FAR from done, so don't jump in and translate things yet, > especially since while I'm doing this, I may clean up some of the original > English strings. Ok, I just thought I'll help look at the strings before we feed it to translators. Mostly it seems as if you were able to hide a lot of the markup, so thanks a lot for that. I'm writing down a few comments that can hopefully make things even easier to translate. * XML entities make things hard to read. If we could use the literal characters and have it converted for us in the code, that would make things much nicer to read, translate and review. I understand why the non-breaking space is desirable in many cases, but something like "BeOS and Haiku" is hard to read, and translators might not be familiar with the issue at hand. Forcing all links not to break, could also cause some strange layout in languages with long translations (I'm just anticipating, of course). There is another reason: people might use something like '&' in a translation, so we need to make it HTML safe before using translations anyway. Therefore I think it is better to work with the assumption that translations won't have correct entities and that we'll create them when rendering. * computer’s - I'm assuming this is an apostrophe. Please just use an apostrophe and encode the page as UTF-8 or whatever you like. This is very error prone, and makes reuse, review and translations hard. * In messages like these... "Alternatively, the Print option can be limited to allow only one print \n every <var>n</var> minutes." ... the layout/spacing serves no purpose, and distracts from the translation task. (I realise that the goal was probably neat HTML layout, but I hope that we realise there are higher goals to aim for.) * "Previewed at" - assume this is lacking a variable for the picture size. Some languages might need to have this reordered with the size in the middle of the translation. By the way, the file currently stands at 255 messages and 1352 words - not too much! I hope this helps. Keep well Friedel -- Recently on my blog: http://translate.org.za/blogs/friedel/en/content/its-easyer-with-kulula |
From: Bill K. <nb...@so...> - 2008-10-30 16:49:36
|
On Thu, Oct 30, 2008 at 12:34:11PM +0200, F Wolff wrote: > * XML entities make things hard to read. If we could use the literal > characters and have it converted for us in the code, that would make > things much nicer to read, translate and review. I understand why the > non-breaking space is desirable in many cases, but something like > "BeOS and Haiku" is hard to read, and translators might not be > familiar with the issue at hand. Forcing all links not to break, could > also cause some strange layout in languages with long translations (I'm > just anticipating, of course). There is another reason: people might use > something like '&' in a translation, so we need to make it HTML safe > before using translations anyway. Therefore I think it is better to work > with the assumption that translations won't have correct entities and > that we'll create them when rendering. Ok, I think we can live without them. Is it safe to run PHP's htmlspecialchars through the results of gettext()? Or will that botch up some UTF-8 characters...? > * computer’s - I'm assuming this is an apostrophe. Please just > use an apostrophe and encode the page as UTF-8 or whatever you like. > This is very error prone, and makes reuse, review and translations hard. Yeah, I don't think it's _necessary_ to have the special quotes, and I never personally put them in, since it's so tedious. I'm all for removing them. > * In messages like these... > "Alternatively, the Print option can be limited to allow only one print > \n > every <var>n</var> minutes." > ... the layout/spacing serves no purpose, and distracts from the > translation task. (I realise that the goal was probably neat HTML > layout, but I hope that we realise there are higher goals to aim for.) Yeah, looks like I forgot to join the lines. > * "Previewed at" - assume this is lacking a variable for the picture > size. Some languages might need to have this reordered with the size in > the middle of the translation. Yeah, another cases where I need printf(), sorry. :) > By the way, the file currently stands at 255 messages and 1352 words - > not too much! Yeah, but I've only done a few pages, so far. I'm wondering, since they're very verbose, and probably less important(?), do you think it would make sense to do the reviews/user comments/schools using it pages separately? (as in, in a separate POT?) Or perhaps it's enough that translators who don't find them important can just ... not translate them. :) > I hope this helps. Yes it does, thanks a lot! -- -bill! "Tux Paint" - free children's drawing software for Windows / Mac OS X / Linux! Download it today! http://www.tuxpaint.org/ |
From: F W. <fr...@tr...> - 2008-10-30 19:35:12
|
On Do, 2008-10-30 at 09:49 -0700, Bill Kendrick wrote: > On Thu, Oct 30, 2008 at 12:34:11PM +0200, F Wolff wrote: > > * XML entities make things hard to read. If we could use the literal > > characters and have it converted for us in the code, that would make > > things much nicer to read, translate and review. I understand why the > > non-breaking space is desirable in many cases, but something like > > "BeOS and Haiku" is hard to read, and translators might not be > > familiar with the issue at hand. Forcing all links not to break, could > > also cause some strange layout in languages with long translations (I'm > > just anticipating, of course). There is another reason: people might use > > something like '&' in a translation, so we need to make it HTML safe > > before using translations anyway. Therefore I think it is better to work > > with the assumption that translations won't have correct entities and > > that we'll create them when rendering. > > Ok, I think we can live without them. Is it safe to run PHP's > htmlspecialchars through the results of gettext()? Or will that botch > up some UTF-8 characters...? I can't speak from experience. I would be terribly disappointed if we couldn't do that, though. A simple test should give you an answer. A quick look at the documentation looks as if it should work. I'm no PHP expert, though. > > * computer’s - I'm assuming this is an apostrophe. Please just > > use an apostrophe and encode the page as UTF-8 or whatever you like. > > This is very error prone, and makes reuse, review and translations hard. > > Yeah, I don't think it's _necessary_ to have the special quotes, and > I never personally put them in, since it's so tedious. I'm all for removing > them. Having the special apostrophe literally as in "computer’s" is not really a problem, since it remains perfectly readable to the translator. Having non-ASCII characters in the English makes some people unhappy, but as long as all the translations use UTF-8 it shouldn't be a problem. > > By the way, the file currently stands at 255 messages and 1352 words - > > not too much! > > Yeah, but I've only done a few pages, so far. I'm wondering, since they're > very verbose, and probably less important(?), do you think it would make > sense to do the reviews/user comments/schools using it pages separately? > (as in, in a separate POT?) > > Or perhaps it's enough that translators who don't find them important can > just ... not translate them. :) You could do it separately. It will make it easy for people to prioritise. If it is easy to spot the unimportant strings a translator could do the same if it is in one file. Both approaches have their advantages and disadvantages. Having a website-extra.pot or whatever might help to focus people's attention on the important stuff and make it seem like less work to contribute to the main website translation. If that isn't too much work for you, perhaps it is worth a try. It is easy to join / split at a later stage to reverse the decision. Keep well Friedel -- Recently on my blog: http://translate.org.za/blogs/friedel/en/content/its-easyer-with-kulula |