Le Sun, 28 Mar 2010 18:01:19 +0200, Jorge G. Mare/aka Koki <koki@xxxxxxxxxxxxx> a écrit:
Hi PulkoMandy, PulkoMandy wrote on Sun, 28 Mar 2010 12:34:37 +0200hta should allow anyone to export a patch with all the files ; commiting it to svn would then be straightforward and could be automated. Unfortunately, this functionality is broken, meaning someone have to change the jamfiles by hand (exporting the catkeys themselves works fine).If you could elaborate on how the functionality is broken and what specific changes need to be made so that the generated patches can be committed to the repo as is, we could:1) Open an issue on HTA for Travis to look into2) Document the process of producing the patches so that more people can potentially step in and reduce your work load
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). 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).
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).
There are two separate tasks here : I was talking about the workflow between hta and the svn to get the catalogs online. It is not expected, as of now, for the translators to take part into this process.Yes, the translators can't commit to SVN. But from what I understand, it could be possible for them to prepare the patches for the developers. A single individual (you) carrying all the load of creating the patches and submitting them to SVN is obviously overwhelming. Instead, if the translators would do the footwork of creating the patches, then all you would have to do is commit them, which would be less burden for you.In fact, I wonder if you have to be the only one committing localization patches. Since HTA can generate patches in bulk (that is, one patch for multiple application catalogs within any given language), then each language team could have one or more members periodically (say, once a week) generate a single patch covering all the recent changes for their language, and then post the patch to Trac. After that, *any* developer with SVN access could commit the patch as is. This could make the process more efficient and would further lower your work load.
See above, about patches collecting dust and bugs in hta that prevent it for going that smoothly.
As for what happens above that (the translation itself), I don't know much about it. I think you could hask Travis and Vincent to coordinate their efforts in making the best tools available...The tools that Travis' and Vicent have developed are great for what they were designed. But we have to look at localization/translation as a whole, rather than building teams around the tools (which is what seems to be happening). Otherwise you will see inconsistencies between the applications and the documentation (they already exist).I think the separate tools can remain where they are; but the place for documenting and communicating everything related to translation/localization needs to be consolidated, so that the people translating the user guide and the applications have a common place where they can communicate and work together, and not in isolation from each other.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. 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.
-- Adrien Destugues / PulkoMandy http://pulkomandy.ath.cx
