On Thu, Nov 18, 2010 at 03:14:33PM +0100, Johanna Ploog wrote:
> On 16 November 2010 16:54, Adam Borowski <kilob...@angband.pl> wrote:
> > On Sun, Nov 14, 2010 at 02:11:41PM +0100, Xavier R wrote:
> >> Also, I want to translate DCSS in french (a huge work, I know, but im ready
> >> :] )
> >> is this possible/viable/cool/etc... ?
>
> Since you're not going to be the only one with that question, he
> pretty much said that the question comes up a lot (lately, that is),
I think I'll better edit the reponse I posted here and put in onto the wiki,
so there's no need to write that over and over.
> that maintaining several distinct translated versions is out of the
> question (Crawl changes too quickly, I think),
This is something that has been tackled by so many projects, and the
standard solution used nowadays is quite well aligned with out development
process, since at least in 0.6 and 0.7 we did have a proper freeze.
It is not completely painless -- there either might be a strict string
freeze which imposes some problems for fixes that would require changing
some strings at the last minute, or no such strict freeze which results in
partially incomplete translations.
It is a cost, but outside the initial internationalization, it's the only
lingering cost on the base. If a translation lags behind, only that
particular translation suffers, not the rest.
Of course, I assume a gettext-like solution. Early Windows string tables
would put a burden, so would keeping translations in-line, so of course none
of these solutions is something we should even think about.
The gettext process is:
* every translateable string is marked up, various tools use different
markups, gettext itself uses _("foo").
* an automated tool goes through the source and collects strings enclosed
in _(""). That list is then put into the translations database.
* translators use some GUI that shows them strings that do not have a
translation to their language. They do this from time to time, as of
course the trunk changes often. Only once a release enters a freeze
there is a big push, asking all translators to get their languages to 100%
coverage.
> that the translation requires internationalization of the code, and that
> doing so is not of high priority at the moment.
It indeed may be a big task, but not an insurmountable one.
You are right, it's not a high prority for any of current official
developers. But this does not mean we should discourage people to give it a
try -- the cost for the core team is coming up with a scheme of encoding the
relation between strings, parameters and language logic. I mean, for a
string "Foo hits bar." we'd need to let the German translation know where it
should put der/die/das and so on. I proposed a very rough sketch of such a
scheme, I'm sure we can come up with something better.
But, about who would do this: I indeed do not volunteer for making all
strings translateable. Coming up with a pluggable scheme that queries a
database and fetches the translation is not a big task, though, and this is
something I certainly help with -- ie, build the foundation.
> > "$ARTICLE(definite, %1) %1 reflects the %2 off $PRONOUN(possessive, %1) %3!"
> > (of course, the actual markup would be much terser)
> >
> > The Polish translation would be:
> > "$NOUN(%1, nominative, singular) $VERB("reflect", $GENDER(%1)) $NOUN(%2,
> > accusative, singular) od swej $NOUN(%3, genitive, singular)!"
> >
> > $VERB(x, y) would provide the declination of word x appropriate for gender
> > y.
> > $NOUN(x, y, z) would take word x, place it in case y and number z.
>
> Sounds good, though I think a previous step is in order that
> differentiates word order by language, i.e. a function that gets passed
> in the subject, action verb and objects and returns a sentence made up of
> language dependent function calls in the required order.
English does have a pretty strict word order, but Polish is pretty loose
there -- and from what I know, Russian allows nearly any permutation for
simple sentences. I was thinking about a shorthand that can be overridden
-- ie, if the symbol is $V, we might write $V(%1) or $V(%1, something) to
have it use the previous word when not mentioned explicitely.
This of course is way, way, way premature. Talking about shorthands for
markup which has not even been devised yet is a waste of time at the moment.
I just mentioned a sample one.
> > After coming up with such a syntax, the biggest part would be going through
> > all the source and replacing all strings this way. If marked in a
> > consistent way (like, _("foo") as gettext uses), we would be able to run
> > some automated tool and gather a list of messages that do need to be
> > translated.
>
> I think Patric Mueller did something similar for NetHack-De: first
> running a script that found all messages (presumably by looking for
> quotation marks) and added a predefined marker in that line (in this
> case "TODO DE").
> Later, it was easy to grep the source for untranslated (or
> half-translated) fragments and translate the messages one line at a
> time.
Unfortunately, that way requires having a distinct source tree for every
language. This is a nightmare. Doing this in a gettext-like way would be
so much better - translations are totally independent from the source, and
you can code as if there weren't any.
Meow!
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Crawl-ref-discuss mailing list
Crawl-ref-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss
