[haiku] Re: Translation/localization info for translators
- From: "Jorge G. Mare/aka Koki" <koki@xxxxxxxxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Mon, 29 Mar 2010 12:01:19 -0700
Hi PulkoMandy,
PulkoMandy wrote on Sun, 28 Mar 2010 22:24:57 +0200
> Travis already knows about it. Basically, there are two problems :
>
> a) Sometimes, and for no apparent reason, the reference to the catkey is
> added at a wrong place in the jamfile (like, right in the middle of the
> .cpp source files).
OK, hopefully Travis will take care of this.
> b) Also, if you generate the patch when something was just commited to
> svn, hta may be out of sync and generate a patch against an old revision,
> thus creating a conflicting patch or reverting someone else work.
>
> The only really useable solution is to take only the catkeys from hta and
> alter the jamfiles by hand. As all the translations change the same line
> in the jamfile, they are likely to create conflicts if the patch isn't
> committed immediately, that's why it's difficult to ask people to commit
> them to trac where they could collect dust and quickly become out of date
> (as soon as another language patch is commited).
Well, the idea would be that if a patch is posted to Trac, then there would be
more hands to submit it to SVN, as opposed to the status quo where you are the
only one dealing with these patches. But I do see your point about the
potential for patches becoming out of sync depending on the timing.
Now, one last (I promise) ignorant question: would it be possible to modify the
build system so that the language catalogs get build by just being added to the
corresponding folder, thus avoiding the need to edit the jam file everytime a
new catalog is added?
> Anyway, it's not the translator work to touch the jamfile. I, or any other
> dev, must do it. As of now, the translations are moving quite fast and
> it's hard to follow for a single person, so yes, some help, from the devs
> with commit access, would be welcome. I guess things will slow down after
> Haiku is fully localized (only new languages and small updates).
That's true. Be prepared to get very busy for the alpha 2 release then. :)
...
> > Perhaps creating an internationalization and localization mailing list
> > would be a good start to spearhed this? Any thoughts?
>
> I think you're actually right about that. Don't bend the workflow around
> the tools, but design the tools that fit the workflow.
>
> As for creating yet another ml : I'm not even sure all people working on
> the translations are subscribed to the existing ones, so, creating yet
> another list may not be that great.
I am not so sure that this is the case. Translators do seem to be using their
respective i18n mailing lists; but these lists are specific to their languages.
There needs to be a more coordinated effort that organizes the localization and
internationalization of Haiku at large, but we do not have a place for it, so
discussions relevant to i18n/i10n are scattered over different places -- i.e.,
HTA, IRC, in private emails, etc. This cannot lead to a concerted effort.
At present, translators are for some reason asked to join the haiku-doc mailing
list; but a list for the "Discussion for the API documentation for the open
source Haiku projec" (copy and paste from the list description) does not seem
to be the right place, does it? :)
I think having a haiku-i18n mailing list to gather people interested/skilled in
internationalization and localization practices would be a good first step to
spearheading a more concerted effort.
> Also, I'd like the workflow to not need me to commit the patches, so it's
> probably not my task to design it. Asking the translators about how they
> think it should work may be a better investigation.
The problem is that translators don't have a clue on how to design or code
build systems. We (translators) can make suggestions, like I am trying to do in
this thread, but in the end the work will have to be done by a developer; until
then, the status quo will continue, and I guess we all have to live with that.
:)
Sorry for the noise. Cheers,
Jorge / aka Koki
Other related posts:
