[haiku] Re: Haiku Translation Assistant ready for action
- From: "Travis D. Reed" <tdreed@xxxxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Sun, 17 Jan 2010 14:41:21 -0600
>> You can't do that with just an svn tree available. You have to actually
build Haiku to extract the catkeys.
There are two ways : do it by hand or use Build-O-Matic. Travis is planning
to use Build-O-Matic, but we have to wait for mmadia to change some things
in it first.
Actually, the system currently works by having a developer in charge of a
translation. When that developer changes anything, they need to manually
upload the {default}.catkeys again. The system will automatically carry over
all the old strings that haven't changed, and fingerprints, etc. are taken
directly from the Default Catalog (i.e. {default}.catkeys).
On dialects: I have to defer to PulkoMandy here. I'm not exactly sure how
this would work. For en_UK.catkeys, only a few strings would be needed:
"Colour," for instance. No need in duplicating strings.
On smart translations and untranslated strings: I'm going to color code as
Marcos suggested. I'll work on that now.
On English as the default: HTA does not expect English to be the default
language, and you may already provide English translations.
Please post your questions as FAQs. That way, we can make a rudimentary help
system.
I've turned on Drupal localization, but wait on that.
--
Travis D. Reed
On Sun, Jan 17, 2010 at 8:24 AM, PulkoMandy <pulkomandy@xxxxxxxxx> wrote:
> We planned automatically harvest en.catkeys as results of the latest
>> build. In this way - newly localized applications will become the
>> corresponding strings table automatically. Existing tables will be also
>> checked for consistency and marked as "changed" if needed.
>>
>
> You can't do that with just an svn tree available. You have to actually
> build Haiku to extract the catkeys.
> There are two ways : do it by hand or use Build-O-Matic. Travis is planning
> to use Build-O-Matic, but we have to wait for mmadia to change some things
> in it first.
>
>
>
>> - I'm not much liking the idea of automatic commits. Doing it by hand
>>> allows me to check there are not big errors (like a missing string), and
>>> also add contributors to AboutSystem. I don't see any way to automate that
>>> :)
>>>
>>
>> Mentioned "HTA operator" responsibility is to check if the build will be
>> not broken and commit approved diffs. The translation consistency is a
>> responsibility of person, translating this strings table. The translator
>> must check the consistency of translation and approve it by marking it
>> "ready for export". I see no technical reasons that can prevent from
>> automatic convertion of the table from the database to catkey. The final
>> decision for commiting will be anyway made by "HTA operator" personally as
>> result of the test build.
>>
>
> This is already done. HTA will even generate a patch, ready for applying to
> an svn tree.
> I still want to apply these patches myself (or anyone else with commit
> access). But it's safer to keep it to the core dev team. Even if nothing
> really bad can happen, it's how it works for pretty much everything else.
>
>
> By the way do you have plans to move all localizations stuff out of the
>> main build procedure? Frankly speaking it become tiresome to build every
>> time the stuff you never need. ;-) May be it can be configurable in
>> UserBuildConfig or made as separate jam target on per-language basis? Good
>> luck!
>>
>
> If you run Haiku, you should be able to test your catkey file by putting it
> along the .catalog without even having to build anything. Or you can run
> linkcatkeys from a bash prompt. If you run another OS, you can't test your
> translations anyway :)
> Actually, there is a couple other possible places where your catkey file
> will be looked for. Check the syslog, the locale kit is quite verbose and
> everything is logged there.
>
>
> --
> Adrien Destugues / PulkoMandy
> http://pulkomandy.ath.cx
>
>
Other related posts:
