Re: What can Git do for translators?
On January 8th, Claude Paroz wrote: > Le jeudi 08 janvier 2009 à 01:16 -0500, Thomas Thurman a écrit : >> 2009/1/7 Sharuzzaman Ahmat Raslan : >> > What I care is my language po file. Maybe around 15KB. >> > >> > Why should I download the whole bunch of data while the one that I need is >> > just a small fraction of it. >> >> Indeed, why should you? You can get it from Damned Lies, can't you? > > The problem is when you want to commit (push) the result upstream. With > svn you can just checkout the po directory. I fear this is not possible > with git (or other DVCS). On a slightly related note, with CVS, we were able to checkout only a few files that we wanted to touch (po/ChangeLog po/sr.po po/LINGUAS) and we were good to go. As far as translators go, the more "advanced" the system, the worse off they are. > But until git is officially in production, we should have the time to > develop the missing piece which is to commit directly from the uploaded > po file on the 'vertimus' section of l10n.gnome.org. Indeed, integration of commit features into damned-lies is the way to go. Cheers, Danilo ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
On Fri, Jan 9, 2009 at 10:35 AM, Leonardo F. Fontenelle wrote: > Em Sex, 2009-01-09 às 03:27 +, Simos Xenitellis escreveu: >> >> The Translation Project (http://translationproject.org/) has (for many >> years now) an automated system where you send the translation file as >> an e-mail attachment and it adds it for you to a common location of >> translation files. >> >> Something that would be desirable with GNOME translations would be to >> able to make easily changes across all the translations of a language, >> and then commit the files in an easy way. >> In KDE, all translations for a specific language reside in a separate >> directory tree, which makes it easy to make overall changes. I think >> the KBabel/Lokalize tool has an option to allow to view all the >> translations in a single list, so that one can identify discrepancies >> in similar terms. >> The same tool has an option to commit (SVN) the translations from >> within the GUI. >> >> Reading about 'git submodule' at >> http://book.git-scm.com/5_submodules.html it looks it might be good to >> try this feature in order to separate the translations from the code >> in each repository. >> > > > I hope the submodule feature works for us. > > I don't like the KDE approach (even if KDE translators don't seem to > bother having scripts changing PO files in the repository), and it works > best with a policy of giving SVN accounts to most regular translators > (that would be circa 10 in my team). > > The TP-Robot approach might work most of the time, if it can receive > screenshots as well. Same for an Web-based approach (e.g. Damned Lies). > > There are some translations which are not in PO files or in screenshots; > e.g. the welcome mail in Evolution. If we get a simple "commit" > interface like TP-Robot or Transifex, then we will need to decide > between keeping translators with commit access or handling exceptional > translations (like the welcome mail) via bug reports. I think the wording here would be that teams would continue to have commit access (in the same sense that developers commit code), and that it is desirable to have some additional automated way, either through the web or by email or even through gtranslator, for those translators that wish to, to add their translations. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Em Sex, 2009-01-09 às 03:27 +, Simos Xenitellis escreveu: > > The Translation Project (http://translationproject.org/) has (for many > years now) an automated system where you send the translation file as > an e-mail attachment and it adds it for you to a common location of > translation files. > > Something that would be desirable with GNOME translations would be to > able to make easily changes across all the translations of a language, > and then commit the files in an easy way. > In KDE, all translations for a specific language reside in a separate > directory tree, which makes it easy to make overall changes. I think > the KBabel/Lokalize tool has an option to allow to view all the > translations in a single list, so that one can identify discrepancies > in similar terms. > The same tool has an option to commit (SVN) the translations from > within the GUI. > > Reading about 'git submodule' at > http://book.git-scm.com/5_submodules.html it looks it might be good to > try this feature in order to separate the translations from the code > in each repository. > I hope the submodule feature works for us. I don't like the KDE approach (even if KDE translators don't seem to bother having scripts changing PO files in the repository), and it works best with a policy of giving SVN accounts to most regular translators (that would be circa 10 in my team). The TP-Robot approach might work most of the time, if it can receive screenshots as well. Same for an Web-based approach (e.g. Damned Lies). There are some translations which are not in PO files or in screenshots; e.g. the welcome mail in Evolution. If we get a simple "commit" interface like TP-Robot or Transifex, then we will need to decide between keeping translators with commit access or handling exceptional translations (like the welcome mail) via bug reports. -- Leonardo Fontenelle http://leonardof.org ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
First of all! Thanks guys. A few months ago I posted a bug, that addresses some of the issues. http://bugzilla.gnome.org/show_bug.cgi?id=554257 I'd like to point some more translator specific ones. Programers write code and commit the changes for other programmers to write code, to commit to other ... , translators commit changes for the users of the desktop and except of reviews, don't expect major changes. They improve their own work. Uploading changes to a ftp should suffice, everything else should be computer's task. I used the translationproject mail system and it was great, if I neglect all the licenses that one has to acquire and one file per mail limit. Language coordinator many times changes a single word in many different po files. Committing all this files is a problem for any system under current features/functionality. In the end you start "collecting" the changes and then just before the cycle is over, you take a day of at work and commit every single file. As I read in previous posts, I also need to make 4 steps to get the job done in svn so moving to git really makes no difference. On the other hand making one folder per language in damn lies would in my view drastically increase the translations, cause instead of committing for 10 hours, I could take new files ... Using such system would benefit on any system used, not breaking the programming. Maybe there is a simpler way, but I am not aware of it and sometimes wonder if I really want to be aware of it. There should also be possibility to commit for "other users". Stats should also be made for translator, but since the translator does not commit, their data is being written to the commiter. Once I found a http://cia.vc/stats/author/ where really nice info is being displayed, but it's not really realistic if the commiter gets all the credit. Stats make you "compete" with others and with yourself. Looking at 99% translated really does make you squeeze some more time, don't you agree? On the Damn lies related side. Currently In the release view table (eg. GNOME 2.26 (Development) ) beside the stats (graph line) of the every project there should be more "quick info" like direct link to the language po file, branch pot file, name of the user who reserved the translation and an indication that a bugreport was send or the translator sent an attachment. Thou the system works fine, I think there are to many mouseclicks that need to be made to get the info. The whatever system used there should be a simple way to get the stats. Matej ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
On Fri, Jan 9, 2009 at 12:19 AM, Federico Mena Quintero wrote: > On Tue, 2009-01-06 at 15:24 +, Simos Xenitellis wrote: > >> The GNOME dev discussion takes place at >> http://mail.gnome.org/archives/desktop-devel-list/2009-January/thread.html#3 >> The discussion is somewhat heated, so it's no place for translators to >> post about. > > The "real" discussion about how the migration is being done is in > gnome-infrastructure: > http://mail.gnome.org/archives/gnome-infrastructure/2009-January/thread.html > > And our scratchpad is here: > http://live.gnome.org/GitMigration > >> If a move eventually takes place, it will require time and effort, so >> it would not happen within the next six months. > > We hope to have working repositories, at least for guinea pigs, within > two weeks :) Moving all the repositories over to git will of course > require time --- it's not the conversion that is the biggest problem, > but fixing the infrastructure and writing documentation. > >> The big question is, how would a DVCS affect the GNOME localisation >> workflows? > > One of my tasks for the migration to Git is to write a little bunch of > tutorials for various scenarios --- maintainers, contributors, > translators, etc. > > However, I'm not 100% sure about the workflows that translators tend to > use. Do people mostly use web tools (and what happens then --- does the > tool commit for them)? Or do they checkout a whole module and simply > commit to the .po files? Or do they checkout a *single* .po file and > then commit it back, or send patches to a language coordinator? Currently, the web tools do not commit translations for the translators in GNOME i18n. Thus, what translators with SVN access do is 1. Checking out a full module and committing the translation (after running 'intltool-update LL', which updates the translation to the latest version of the code) 2. Checking out just the po/ subdirectory and committing the translation. It is not common to send patches of PO files for committing because the reference files provided from damned-lies may change at any time when new translation strings are added. The Translation Project (http://translationproject.org/) has (for many years now) an automated system where you send the translation file as an e-mail attachment and it adds it for you to a common location of translation files. Something that would be desirable with GNOME translations would be to able to make easily changes across all the translations of a language, and then commit the files in an easy way. In KDE, all translations for a specific language reside in a separate directory tree, which makes it easy to make overall changes. I think the KBabel/Lokalize tool has an option to allow to view all the translations in a single list, so that one can identify discrepancies in similar terms. The same tool has an option to commit (SVN) the translations from within the GUI. Reading about 'git submodule' at http://book.git-scm.com/5_submodules.html it looks it might be good to try this feature in order to separate the translations from the code in each repository. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
У чет, 08. 01 2009. у 18:19 -0600, Federico Mena Quintero пише: > > However, I'm not 100% sure about the workflows that translators tend to > use. > Usually every team has a few people who are commiters (including team coordinator). People that just want to do translation, they tend to download updated PO file from Damned Lies (http://l10n.gnome.org) and send it to project mailing list, coordinator or one of "trusted commiters". Now it's possible to send it to commiters via Damned Lies too. There are also people that want to peek inside sources while translating or they want to test translations by building and running applications so they like to checkout complete module. No difference from any other here. Somebody said in this thread that there are people that want to fetch just "po" subdir. The only scenario I can came up with is that there are commiters with slow Internet access... In any case they must download PO file from Damned Lies as source is needed to update file with new messages. Translators who don't need complete source can download tarball with all PO files from Damned Lies. Review process is important inside workflow, and I think that every team has its own best practice according to team size and resources, but I don't believe it is different than translating from a perspective of version control. And everybody need revisions (even broken ones with non-aligned PO files are better than none). Those without sources can use viewvc interface. After getting two versions (by download or checkout), one must align two PO files with msgcat tool before doing diff. (Get revision from last review, align it with trunk and then compare in diff-tool like meld to review changes and fix errors, for example) Inside string freeze some modules branch early for release and commiters need to commit translation both to string-frozen branch and later to trunk (I like to do this immediately not to forget later). Once again, there is noting translation-specific inside. For large teams, it may prove (I'm just guessing, Serbian team is small) useful to have one repository for all PO files, grouped by language so translators, editors, commiters and coordinator can all work in a distributed environment without cloning everything else. This would in addition solve repository-size issue too, and those wanting sources can get them too. KDE is using this approach. It is important to note that not having this will NOT be a drawback from current svn-based solution and we can always think about it in the future. -- Goran ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Leonardo F. Fontenelle wrote: > As a translator, I just have to check out the po/ or help/ subdirs where > I want to commit my translation files to. There's even a LINGUAS file in > the po/ subdirs to avoid translators checking out the whole module just > to edit Makefile.am. The main reason to move to LINGUAS was in fact to make it less error prune for translators. Previously we were left with many broken builds because, eg, the editor decided to break the line and the translator (not exactly savvy in configure.ac syntax) didn't notice. > AFAIK moving to git would mean committers must checkout the whole > module. That's assuming that the transition team does not find a solution to this problem. Lets not speculate and focus on the problems that need to be solved. That's why Federico is here asking you what your workflow is. If the transition happens and you are left in the cold having to download the full module to commit one file, you have all rights to complain :). Cheers, behdad > If it can't be worked around, it will be a major problem for > most translation teams. Brazil is not exactly a poor country, and > 128kbps is still called "broadband" here. > ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Em Qui, 2009-01-08 às 18:19 -0600, Federico Mena Quintero escreveu: > The "real" discussion about how the migration is being done is in > gnome-infrastructure: > http://mail.gnome.org/archives/gnome-infrastructure/2009-January/thread.html > Thanks for clarifying this. > However, I'm not 100% sure about the workflows that translators tend to > use. Do people mostly use web tools (and what happens then --- does the > tool commit for them)? Or do they checkout a whole module and simply > commit to the .po files? Or do they checkout a *single* .po file and > then commit it back, or send patches to a language coordinator? > Currently translations must be committed by translator with svn access. Adding committing capabilities in Damned Lies is somewhat in the roadmap, but currently the developers are implementing more basic features, like team management. As a translator, I just have to check out the po/ or help/ subdirs where I want to commit my translation files to. There's even a LINGUAS file in the po/ subdirs to avoid translators checking out the whole module just to edit Makefile.am. AFAIK moving to git would mean committers must checkout the whole module. If it can't be worked around, it will be a major problem for most translation teams. Brazil is not exactly a poor country, and 128kbps is still called "broadband" here. -- Leonardo Fontenelle http://leonardof.org ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
On Tue, 2009-01-06 at 15:24 +, Simos Xenitellis wrote: > The GNOME dev discussion takes place at > http://mail.gnome.org/archives/desktop-devel-list/2009-January/thread.html#3 > The discussion is somewhat heated, so it's no place for translators to > post about. The "real" discussion about how the migration is being done is in gnome-infrastructure: http://mail.gnome.org/archives/gnome-infrastructure/2009-January/thread.html And our scratchpad is here: http://live.gnome.org/GitMigration > If a move eventually takes place, it will require time and effort, so > it would not happen within the next six months. We hope to have working repositories, at least for guinea pigs, within two weeks :) Moving all the repositories over to git will of course require time --- it's not the conversion that is the biggest problem, but fixing the infrastructure and writing documentation. > The big question is, how would a DVCS affect the GNOME localisation workflows? One of my tasks for the migration to Git is to write a little bunch of tutorials for various scenarios --- maintainers, contributors, translators, etc. However, I'm not 100% sure about the workflows that translators tend to use. Do people mostly use web tools (and what happens then --- does the tool commit for them)? Or do they checkout a whole module and simply commit to the .po files? Or do they checkout a *single* .po file and then commit it back, or send patches to a language coordinator? Federico ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Jumping in in the middle again, with some experience from Mozilla after our switch to hg: One of they key questions when moving to a dvcs is what goes into which repo. This isn't really a requirement of a dvcs, but seems to come with the design of at least hg, and from glancing at it, git, too. DVCSes are bad at partial clones. In hg it's straight out impossible, and I haven't seen an obvious way in git. From my understanding, this comes from having a unique identifier for a repo so that you know where local commits would go when you push back upstream or round-robin or in circles and whatnot. What we do in Mozilla is: - one repo for Firefox and Toolkit - one repo for Thunderbird and Calendar and most parts of SeaMonkey - helluva more repos on hg or cvs for SeaMonkey - one repo for each localization for all three products The rationale for using a single repo per locale, and to not mirror the split in the en-US products was to optimize for smaller teams, where it's mostly one person working on everything anyway, and to not have them go through 5 repos for one locale. The downside is that for bigger teams with more than one committer, each contributor ends up having to pull and merge other apps and contributions before being able to push their own changes. In particular as we only allow one head per named branch on the repos. (User repos don't have that constraint, though.) There has been a rather lengthy discussion in our community if that's the right choice, both on the en-US side and the l10n side. The benefits of a DVCS just ask for a different set of compromises, sadly. I can't really tell which setup would be right for GNOME, as I don't know the community nor the module structure well enough, but if you have concrete questions, I'll try to come up with concrete answers. Another thing, release tags are a common source of grief, as that's a given landing on the l10n repos that are not done by the localization teams, and thus require them to pull and merge, or not, depending on their local status. HTH Axel 2009/1/8 Gabor Kelemen > Thomas Thurman írta: > > 2009/1/7 Sharuzzaman Ahmat Raslan : > >> What I care is my language po file. Maybe around 15KB. > >> > >> Why should I download the whole bunch of data while the one that I need > is > >> just a small fraction of it. > > > > Indeed, why should you? You can get it from Damned Lies, can't you? > > > > Because I want/have to do > > $ git push > > Or can git check out only a single directory or file? I seriously don't > know, so don't take it as an offence. > > I'm asking this because checking out anything other than $LANG.po and > Changelog, optionally LINGUAS is not really necessary for doing > translations. (CVS could do this! ;)) > > With SVN, we have to check out at least the po directory - not much more > data, but still worse than CVS wrt to saving badwidth. Taking one more > step backwards and having to download an entire repo would be quite bad > in this regard - at least for those with limited bandwidth and until > Transifex saves them. > > Regards > Gabor Kelemen > ___ > gnome-i18n mailing list > gnome-i18n@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-i18n > ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Claude Paroz and Gabor Kelemen shared my concern very well. Thanks. 2009/1/8 Gabor Kelemen > Thomas Thurman írta: > > 2009/1/7 Sharuzzaman Ahmat Raslan : > >> What I care is my language po file. Maybe around 15KB. > >> > >> Why should I download the whole bunch of data while the one that I need > is > >> just a small fraction of it. > > > > Indeed, why should you? You can get it from Damned Lies, can't you? > > > > Because I want/have to do > > $ git push > > Or can git check out only a single directory or file? I seriously don't > know, so don't take it as an offence. > > I'm asking this because checking out anything other than $LANG.po and > Changelog, optionally LINGUAS is not really necessary for doing > translations. (CVS could do this! ;)) > > With SVN, we have to check out at least the po directory - not much more > data, but still worse than CVS wrt to saving badwidth. Taking one more > step backwards and having to download an entire repo would be quite bad > in this regard - at least for those with limited bandwidth and until > Transifex saves them. > > Regards > Gabor Kelemen > ___ > gnome-i18n mailing list > gnome-i18n@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-i18n > -- Sharuzzaman Ahmat Raslan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Thomas Thurman írta: > 2009/1/7 Sharuzzaman Ahmat Raslan : >> What I care is my language po file. Maybe around 15KB. >> >> Why should I download the whole bunch of data while the one that I need is >> just a small fraction of it. > > Indeed, why should you? You can get it from Damned Lies, can't you? > Because I want/have to do $ git push Or can git check out only a single directory or file? I seriously don't know, so don't take it as an offence. I'm asking this because checking out anything other than $LANG.po and Changelog, optionally LINGUAS is not really necessary for doing translations. (CVS could do this! ;)) With SVN, we have to check out at least the po directory - not much more data, but still worse than CVS wrt to saving badwidth. Taking one more step backwards and having to download an entire repo would be quite bad in this regard - at least for those with limited bandwidth and until Transifex saves them. Regards Gabor Kelemen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Le jeudi 08 janvier 2009 à 01:16 -0500, Thomas Thurman a écrit : > 2009/1/7 Sharuzzaman Ahmat Raslan : > > What I care is my language po file. Maybe around 15KB. > > > > Why should I download the whole bunch of data while the one that I need is > > just a small fraction of it. > > Indeed, why should you? You can get it from Damned Lies, can't you? The problem is when you want to commit (push) the result upstream. With svn you can just checkout the po directory. I fear this is not possible with git (or other DVCS). But until git is officially in production, we should have the time to develop the missing piece which is to commit directly from the uploaded po file on the 'vertimus' section of l10n.gnome.org. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Well I think there is really more than one discussion now in this
thread. For my own sake, I'm a commiter and translator. I _want_ to be
able to get the source of a branch (that's just my choise), so if what
is written above is true, that I can still do that and it wont fill up
terribly more (or perhaps even less) on my HD, then it doesn't really
matter to me what system we use. I should be able to learn 6 commands
in any (D)VCS.
Then there is the other discussion, about what kind of work practices
it is really reasonable to ask translators to use (i.e. how much you
can ask them to download and what they need to do to translate). I
that sense, as long as git does not make anything any worse, then
there really shouldn't be an issue switching.
1. Translators can always get an updated po-files from damned lies
(git or no git)
2. If they want to get the po-file from source code then they can stil
do that (nomatter whether it is git or svn, and apparently with no
bigger downloads)
3. If they want to just get the source code to figure out the context
of strings, then they can stil do that (nomatter whether it is git or
svn, and apparently with no bigger downloads)
So if what I have understood about how this system works, I don't see
that big fuss. No improvements for us, but no disadvantages either.
Regards Kenneth Nielsen
2009/1/8 Simos Xenitellis :
> On Thu, Jan 8, 2009 at 1:19 AM, Shaun McCance wrote:
>> Hi Simos,
>>
>> I don't want to detract from this conversation, because I think
>> it's important to consider how this would impact all of Gnom's
>> contributors, including translators, documentation folks, etc.
>> A switch would have at least some impact on everybody, and we
>> need to know how to deal with problems.
>>
>> But...
>>
>>> Scenario A
>>> => Using command line tools, we add a translation to the main repository.
>>>
>>> Assume the repository is git://git.gnome.org/gnome-games.git
>>> we make a local copy by 'cloning' the repository ('checkout' is
>>> something different in git)
>>>
>>> git clone git://git.gnome.org/gnome-games.git
>>>
>>> This would create a very big tree, because it would make a full
>>> offline copy, with all the history for the last ten years or so. When
>>> we use SVN, a checkout of gnome-games is 124MB. The approximate size
>>> of a 'git clone' should be quite larger. My test with 'git-svn clone'
>>> was not conclusive (due to the way it works, it is very slow, I
>>> stopped after an hour, which it downloaded 74MB).
>>
>> I want to first point out that it's slow because it's git-svn.
>> I don't want people to think it would be this terribly slow if
>> we were using git. Cloning from a git server is quite fast.
>>
>> More importantly, you'd be surprised at just how small a git
>> clone actually is. I have both a git clone and an svn checkout
>> of gnome-doc-utils. The svn checkout is 38MB. The git clone
>> is 26MB. Seriously, it's smaller. And the git clone has more
>> commits that aren't in SVN yet.
>
> Hi Shaun,
>
> This is the kind of information we need. That a possible move to git
> will not cause issues with the current translation practices.
>
> Therefore, for a coordinator that wants to update a translation the
> manual way, the steps would be something like
>
> 1. Get a copy of the repository for the package (i.e. gnome-games)
> $ git clone git://git.gnome.org/gnome-games.git
> Initialized empty Git repository in /tmp/gnome-games/.git/
> remote: Counting objects: 8728, done.
> remote: Compressing objects: 100% (8712/8712), done.
> remote: Total 8728 (delta 3431), reused 0 (delta 0)
> Receiving objects: 100% (8728/8728), 71541.07 KiB | 239 KiB/s, done.
> Resolving deltas: 100% (431/431), done.
> $ _
>
> 2. Update the translation
> $ cd gnome-games/po
> $ intltool-update el
>
>
> 3. Commit first the translation to the local copy of the repository.
> $ git commit -a -m "Updated my translation"
> Created commit 22783ff: Updated translation.
> 1 files changed, 1 insertions(+), 0 deletions(-)
> $ _
>
> 4. Push the change to the remote repository at git.gnome.org
> $ git push
> Counting objects: 5, done.
> Compressing objects: 100% (3/3), done.
> Writing objects: 100% (3/3), 316 bytes, done.
> Total 3 (delta 2), reused 0 (delta 0)
> To g...@git.gnome.org:simos/gnome-games.git
> ff4bf15..22783ff el -> el
> $ _
>
> 5. That's it!
>
> A practical comparison between git and other DVCSs (and SVN) is at
> http://www.whygitisbetterthanx.com/
>
> Simos
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
2009/1/7 Sharuzzaman Ahmat Raslan : > What I care is my language po file. Maybe around 15KB. > > Why should I download the whole bunch of data while the one that I need is > just a small fraction of it. Indeed, why should you? You can get it from Damned Lies, can't you? Thomas ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
That's look nice, but I don't really want to download about 75MB of data
just to translate my language.
What I care is my language po file. Maybe around 15KB.
Why should I download the whole bunch of data while the one that I need is
just a small fraction of it.
Remember, not all people have unlimited Internet connection. Some is being
charged by the volume of data transferred. So asking translator to download
the whole set of source is not practical.
Some people also have very slow connection. So they are only interested to
get the file that is related to them, that can be fetched quickly even with
slow connection. Big data will cause them to wait more.
On Thu, Jan 8, 2009 at 10:22 AM, Simos Xenitellis <
simos.li...@googlemail.com> wrote:
> On Thu, Jan 8, 2009 at 1:19 AM, Shaun McCance wrote:
> > Hi Simos,
> >
> > I don't want to detract from this conversation, because I think
> > it's important to consider how this would impact all of Gnom's
> > contributors, including translators, documentation folks, etc.
> > A switch would have at least some impact on everybody, and we
> > need to know how to deal with problems.
> >
> > But...
> >
> >> Scenario A
> >> => Using command line tools, we add a translation to the main
> repository.
> >>
> >> Assume the repository is git://git.gnome.org/gnome-games.git
> >> we make a local copy by 'cloning' the repository ('checkout' is
> >> something different in git)
> >>
> >> git clone git://git.gnome.org/gnome-games.git
> >>
> >> This would create a very big tree, because it would make a full
> >> offline copy, with all the history for the last ten years or so. When
> >> we use SVN, a checkout of gnome-games is 124MB. The approximate size
> >> of a 'git clone' should be quite larger. My test with 'git-svn clone'
> >> was not conclusive (due to the way it works, it is very slow, I
> >> stopped after an hour, which it downloaded 74MB).
> >
> > I want to first point out that it's slow because it's git-svn.
> > I don't want people to think it would be this terribly slow if
> > we were using git. Cloning from a git server is quite fast.
> >
> > More importantly, you'd be surprised at just how small a git
> > clone actually is. I have both a git clone and an svn checkout
> > of gnome-doc-utils. The svn checkout is 38MB. The git clone
> > is 26MB. Seriously, it's smaller. And the git clone has more
> > commits that aren't in SVN yet.
>
> Hi Shaun,
>
> This is the kind of information we need. That a possible move to git
> will not cause issues with the current translation practices.
>
> Therefore, for a coordinator that wants to update a translation the
> manual way, the steps would be something like
>
> 1. Get a copy of the repository for the package (i.e. gnome-games)
> $ git clone git://git.gnome.org/gnome-games.git
> Initialized empty Git repository in /tmp/gnome-games/.git/
> remote: Counting objects: 8728, done.
> remote: Compressing objects: 100% (8712/8712), done.
> remote: Total 8728 (delta 3431), reused 0 (delta 0)
> Receiving objects: 100% (8728/8728), 71541.07 KiB | 239 KiB/s, done.
> Resolving deltas: 100% (431/431), done.
> $ _
>
> 2. Update the translation
> $ cd gnome-games/po
> $ intltool-update el
>
>
> 3. Commit first the translation to the local copy of the repository.
> $ git commit -a -m "Updated my translation"
> Created commit 22783ff: Updated translation.
> 1 files changed, 1 insertions(+), 0 deletions(-)
> $ _
>
> 4. Push the change to the remote repository at git.gnome.org
> $ git push
> Counting objects: 5, done.
> Compressing objects: 100% (3/3), done.
> Writing objects: 100% (3/3), 316 bytes, done.
> Total 3 (delta 2), reused 0 (delta 0)
> To g...@git.gnome.org:simos/gnome-games.git
> ff4bf15..22783ff el -> el
> $ _
>
> 5. That's it!
>
> A practical comparison between git and other DVCSs (and SVN) is at
> http://www.whygitisbetterthanx.com/
>
> Simos
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-i18n
>
--
Sharuzzaman Ahmat Raslan
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
On Thu, Jan 8, 2009 at 1:19 AM, Shaun McCance wrote:
> Hi Simos,
>
> I don't want to detract from this conversation, because I think
> it's important to consider how this would impact all of Gnom's
> contributors, including translators, documentation folks, etc.
> A switch would have at least some impact on everybody, and we
> need to know how to deal with problems.
>
> But...
>
>> Scenario A
>> => Using command line tools, we add a translation to the main repository.
>>
>> Assume the repository is git://git.gnome.org/gnome-games.git
>> we make a local copy by 'cloning' the repository ('checkout' is
>> something different in git)
>>
>> git clone git://git.gnome.org/gnome-games.git
>>
>> This would create a very big tree, because it would make a full
>> offline copy, with all the history for the last ten years or so. When
>> we use SVN, a checkout of gnome-games is 124MB. The approximate size
>> of a 'git clone' should be quite larger. My test with 'git-svn clone'
>> was not conclusive (due to the way it works, it is very slow, I
>> stopped after an hour, which it downloaded 74MB).
>
> I want to first point out that it's slow because it's git-svn.
> I don't want people to think it would be this terribly slow if
> we were using git. Cloning from a git server is quite fast.
>
> More importantly, you'd be surprised at just how small a git
> clone actually is. I have both a git clone and an svn checkout
> of gnome-doc-utils. The svn checkout is 38MB. The git clone
> is 26MB. Seriously, it's smaller. And the git clone has more
> commits that aren't in SVN yet.
Hi Shaun,
This is the kind of information we need. That a possible move to git
will not cause issues with the current translation practices.
Therefore, for a coordinator that wants to update a translation the
manual way, the steps would be something like
1. Get a copy of the repository for the package (i.e. gnome-games)
$ git clone git://git.gnome.org/gnome-games.git
Initialized empty Git repository in /tmp/gnome-games/.git/
remote: Counting objects: 8728, done.
remote: Compressing objects: 100% (8712/8712), done.
remote: Total 8728 (delta 3431), reused 0 (delta 0)
Receiving objects: 100% (8728/8728), 71541.07 KiB | 239 KiB/s, done.
Resolving deltas: 100% (431/431), done.
$ _
2. Update the translation
$ cd gnome-games/po
$ intltool-update el
3. Commit first the translation to the local copy of the repository.
$ git commit -a -m "Updated my translation"
Created commit 22783ff: Updated translation.
1 files changed, 1 insertions(+), 0 deletions(-)
$ _
4. Push the change to the remote repository at git.gnome.org
$ git push
Counting objects: 5, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 316 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
To g...@git.gnome.org:simos/gnome-games.git
ff4bf15..22783ff el -> el
$ _
5. That's it!
A practical comparison between git and other DVCSs (and SVN) is at
http://www.whygitisbetterthanx.com/
Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Hi Simos,
I don't want to detract from this conversation, because I think
it's important to consider how this would impact all of Gnom's
contributors, including translators, documentation folks, etc.
A switch would have at least some impact on everybody, and we
need to know how to deal with problems.
But...
> Scenario A
> => Using command line tools, we add a translation to the main repository.
>
> Assume the repository is git://git.gnome.org/gnome-games.git
> we make a local copy by 'cloning' the repository ('checkout' is
> something different in git)
>
> git clone git://git.gnome.org/gnome-games.git
>
> This would create a very big tree, because it would make a full
> offline copy, with all the history for the last ten years or so. When
> we use SVN, a checkout of gnome-games is 124MB. The approximate size
> of a 'git clone' should be quite larger. My test with 'git-svn clone'
> was not conclusive (due to the way it works, it is very slow, I
> stopped after an hour, which it downloaded 74MB).
I want to first point out that it's slow because it's git-svn.
I don't want people to think it would be this terribly slow if
we were using git. Cloning from a git server is quite fast.
More importantly, you'd be surprised at just how small a git
clone actually is. I have both a git clone and an svn checkout
of gnome-doc-utils. The svn checkout is 38MB. The git clone
is 26MB. Seriously, it's smaller. And the git clone has more
commits that aren't in SVN yet.
--
Shaun
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
On Wed, Jan 7, 2009 at 11:32 PM, Leonardo F. Fontenelle wrote: > Em Qui, 2009-01-08 às 00:23 +0100, Axel Hecht escreveu: >> Jumping in to this discussion at some random point: >> >> I think that DVCSes can add value to localizers. In particular for >> projects that have in-development l10n, but probably for other >> projects, too. >> >> The main value a DVCS gives to localizers is coming from exposing the >> history of the original language, though. I can see good value in >> exposing localizable strings to the localizer in changesets as they >> were added to the original language, as they're likely going to belong >> to the same context. So while going through a file of localizable >> strings from top to bottom, you would have to go through several >> context switches, going through the localizable strings patch-wise >> might come with less contex switches. >> >> That of course is more of a job and an opportunity for translation >> tools than anything else. >> > > At least with GNU Gettext, running msgmerge will move translations from > one line to another without hesitation, and automatic comments are > always there to add noive to diffs. If any dcvs can work around this > adversities, I'll defend its adoption. Today, if I need to read a diff > between message catalogs, I run "msgcat file.po -o file.po" (because > some translators use poEdit), then msgmerge between both of them and the > same POT, or usually between the oldest and the newest (from DL), and > only then I can get a readable diff. Off-topic, po-diff related. There is podiff that allows to diff two po files. It produces output that looks like --- Modified Message: 'Iagno Manual V2.8' Old: 'Τεκμηρίωση του Ιάγνος, έκδοση 2.7' New: 'Τεκμηρίωση του Ιάγνος, έκδοση 2.8' Available from https://edge.launchpad.net/podiff Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Em Qui, 2009-01-08 às 00:23 +0100, Axel Hecht escreveu: > Jumping in to this discussion at some random point: > > I think that DVCSes can add value to localizers. In particular for > projects that have in-development l10n, but probably for other > projects, too. > > The main value a DVCS gives to localizers is coming from exposing the > history of the original language, though. I can see good value in > exposing localizable strings to the localizer in changesets as they > were added to the original language, as they're likely going to belong > to the same context. So while going through a file of localizable > strings from top to bottom, you would have to go through several > context switches, going through the localizable strings patch-wise > might come with less contex switches. > > That of course is more of a job and an opportunity for translation > tools than anything else. > At least with GNU Gettext, running msgmerge will move translations from one line to another without hesitation, and automatic comments are always there to add noive to diffs. If any dcvs can work around this adversities, I'll defend its adoption. Today, if I need to read a diff between message catalogs, I run "msgcat file.po -o file.po" (because some translators use poEdit), then msgmerge between both of them and the same POT, or usually between the oldest and the newest (from DL), and only then I can get a readable diff. -- Leonardo Fontenelle http://leonardof.org ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Jumping in to this discussion at some random point: I think that DVCSes can add value to localizers. In particular for projects that have in-development l10n, but probably for other projects, too. The main value a DVCS gives to localizers is coming from exposing the history of the original language, though. I can see good value in exposing localizable strings to the localizer in changesets as they were added to the original language, as they're likely going to belong to the same context. So while going through a file of localizable strings from top to bottom, you would have to go through several context switches, going through the localizable strings patch-wise might come with less contex switches. That of course is more of a job and an opportunity for translation tools than anything else. Axel 2009/1/7 Leonardo F. Fontenelle > Em Ter, 2009-01-06 às 15:24 +, Simos Xenitellis escreveu: > > Hi All, > > > > There is a discussion on the gnome developer mailing lists regarding a > > possible move from Subversion (SVN) to a Distributed Version Control > > System (DVCS) such as git, which is already used for the Linux kernel, > > Perl, some libraries such as clutter. This post is to help contribute > > to the discussion. > > > > [...] > > > > As a translator I can't see any benefit in a distributed VCS. We work > with _the_ version with _the_ strings; heck, we have even string > freezes! > > Regular translators shouldn't use svn already, because damned lies realy > adds value to the repository (updated message catalogs, alerts, > statistics etc.). But someone must commit the translations, and that > would be the team leaders and a few more translators. > > If damned-lies ever learns to commit translations and "translated" and > other stuff, then translators shouldn't have to care about the VCS. > Otherwise, I wouldn't like to have to learn git or bzr. > > -- > Leonardo Fontenelle > http://leonardof.org > > ___ > gnome-i18n mailing list > gnome-i18n@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-i18n > ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Em Ter, 2009-01-06 às 15:24 +, Simos Xenitellis escreveu: > Hi All, > > There is a discussion on the gnome developer mailing lists regarding a > possible move from Subversion (SVN) to a Distributed Version Control > System (DVCS) such as git, which is already used for the Linux kernel, > Perl, some libraries such as clutter. This post is to help contribute > to the discussion. > > [...] > As a translator I can't see any benefit in a distributed VCS. We work with _the_ version with _the_ strings; heck, we have even string freezes! Regular translators shouldn't use svn already, because damned lies realy adds value to the repository (updated message catalogs, alerts, statistics etc.). But someone must commit the translations, and that would be the team leaders and a few more translators. If damned-lies ever learns to commit translations and "translated" and other stuff, then translators shouldn't have to care about the VCS. Otherwise, I wouldn't like to have to learn git or bzr. -- Leonardo Fontenelle http://leonardof.org ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Hi! > And obviously, posting all this commands listings, their replacements, > tips, optionals workflows and the likes in a wiki page in live.gnome.org > is the most needed. > This is just a sidenote not really related: I discussed with some hg and git people on the Google Summer of Code Summit about the problems with switching to a DVCS for translators. They told me that they think that for translators a web based system is much better than any VCS. I think they are probably right. That does not mean that the translations shouldn't be in a DVCS but that there should be a web based way to access/change them. I know there are some projects out there that allow this and that damned-lies could probably be expanded to support this. But it would make the DVCS problem disappear completely for people who don't want to use it. Regards, Johannes signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
My point of view is that we just need to know a replace for:
svn co
svn up
svn status
svn diff
svn ci
Everything else can be either scripted from the above replacement
commands or either is specific for someone's way of work (that will be
also the same as for the above commands, so if she/he has taken her/his
time to know how to do, it can do the same when me move to $DVCS).
And obviously, posting all this commands listings, their replacements,
tips, optionals workflows and the likes in a wiki page in live.gnome.org
is the most needed.
My 5 cents,
Cheers,
El dt 06 de 01 de 2009 a les 15:24 +, en/na Simos Xenitellis va
escriure:
> Hi All,
>
> There is a discussion on the gnome developer mailing lists regarding a
> possible move
> from Subversion (SVN) to a Distributed Version Control System (DVCS)
> such as git, which is already used for the Linux kernel, Perl, some
> libraries such as clutter.
> This post is to help contribute to the discussion.
>
> If you are a GNOME Foundation member, you probably got a survey e-mail
> in December on the issue.
>
> The survey results are at
> http://blogs.gnome.org/newren/2009/01/03/gnome-dvcs-survey-results/
> http://mces.blogspot.com/2009/01/gnome-dvcs-survey.html
>
> The GNOME dev discussion takes place at
> http://mail.gnome.org/archives/desktop-devel-list/2009-January/thread.html#3
> The discussion is somewhat heated, so it's no place for translators to
> post about.
>
> If a move eventually takes place, it will require time and effort, so
> it would not happen within the next six months.
>
> Moving from Subversion (SVN) to a DVCS such as git will have lots of
> benefits for the developers, which is very important. Normally, we
> expect the KDE project to try these things out first but this time it
> appears they are sticking with SVN.
>
> In general, learning a DVCS such as git is a new modern skill. There
> are books available,
> http://book.git-scm.com/ and you can try it out with a free repository
> (100MB) at https://github.com/ or at Gitorious, http://gitorious.org/
>
> The big question is, how would a DVCS affect the GNOME localisation workflows?
> Are we going to keep the same easy facilities? Is a DVCS going to make
> some things easier?
> Is there another big project which supports localisation to many
> languages, and it uses a DVCS?
>
> Scenario A
> => Using command line tools, we add a translation to the main repository.
>
> Assume the repository is git://git.gnome.org/gnome-games.git
> we make a local copy by 'cloning' the repository ('checkout' is
> something different in git)
>
> git clone git://git.gnome.org/gnome-games.git
>
> This would create a very big tree, because it would make a full
> offline copy, with all the history for the last ten years or so. When
> we use SVN, a checkout of gnome-games is 124MB. The approximate size
> of a 'git clone' should be quite larger. My test with 'git-svn clone'
> was not conclusive (due to the way it works, it is very slow, I
> stopped after an hour, which it downloaded 74MB).
>
> It might be possible to use the --depth parameter in 'git clone',
> which can limit how far back the history will go to. Reading the man
> page for git-clone, it is not clear if we would be able to 'push' (or
> 'commit' per SVN) the changes back to the tree.
>
>--depth
>Create a shallow clone with a history truncated to the
> specified number of revisions. A shallow repository has a number of
> limitations (you
>cannot clone or fetch from it, nor push from nor into it),
> but is adequate if you are only interested in the recent history of a
> large project
>with a long history, and would want to send in fixes as patches.
>
> Scenario B
> damned-lies and vertimus should be rather easy to convert to git,
> since they would simply need to replace 'svn checkout' with 'git clone
> --depth 0'.
> Is that the case?
>
> Are there any other issues we need to think about?
>
> Simos
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-i18n
--
gil forcada
[ca] guifi.net - una xarxa lliure que no para de créixer
[en] guifi.net - a non-stopping free network
bloc: http://gil.badall.net
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
2009-01-06 klockan 17:34 skrev Jorge González González: > El mar, 06-01-2009 a las 17:22 +0100, Stéphane Raimbault escribió: > > 2009/1/6 Jorge González González > > > > No, I don't think translators must download the whole GNOME > > SVN just to > > translate. > > > > If you mean with history, of course, no! > > > > We provide an _updated_ PO file in Damned Lies (update to date with > > the source code), it's not the case if you get the file with svn co, > > or git clone --depth or bzr branch --stacked, or insert your prefered > > DVCS here). > Yes, I know DL provides the lastest po file, but I mean that I only > checkout the po and help/doc directories, not the full piece of > software. I simply do not have time to compile every application I > translate. Having the source available is not the same as actually compiling it. Personally, I almost always use the source code when translating. — Wouter signature.asc Description: Digital signature ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
El mar, 06-01-2009 a las 17:22 +0100, Stéphane Raimbault escribió: > 2009/1/6 Jorge González González > > No, I don't think translators must download the whole GNOME > SVN just to > translate. > > If you mean with history, of course, no! > > We provide an _updated_ PO file in Damned Lies (update to date with > the source code), it's not the case if you get the file with svn co, > or git clone --depth or bzr branch --stacked, or insert your prefered > DVCS here). Yes, I know DL provides the lastest po file, but I mean that I only checkout the po and help/doc directories, not the full piece of software. I simply do not have time to compile every application I translate. Cheers. -- Jorge González González Weblog: http://aloriel.no-ip.org Fotolog: http://www.flickr.com/photos/aloriel ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
2009/1/6 Jorge González González > > No, I don't think translators must download the whole GNOME SVN just to > translate. If you mean with history, of course, no! We provide an _updated_ PO file in Damned Lies (update to date with the source code), it's not the case if you get the file with svn co, or git clone --depth or bzr branch --stacked, or insert your prefered DVCS here). ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
2009/1/6 Simos Xenitellis > Scenario B > damned-lies and vertimus should be rather easy to convert to git, > since they would simply need to replace 'svn checkout' with 'git clone > --depth 0'. > Is that the case? > > Damned-Lies is already able to talk with cvs, svn, hg, git and bzr ! See checkout() method of Branch: http://svn.gnome.org/viewvc/damned-lies/trunk/stats/models.py?revision=1294&view=markup Stephane PS: git clone --depth 0 is not required (on server and block the using of git switch afterward) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Hi, El mar, 06-01-2009 a las 17:09 +0100, Stéphane Raimbault escribió: > 2009/1/6 Sharuzzaman Ahmat Raslan > Hi all, > > I would suggest that GNOME create a tree specifically for > translation. > > gnome-po.git should be nice. > > Then translator only need to clone the tree related to > translation and start translating. > > I often need the source code to check the context or test my > translation, not you? I personally don't, when I'm in a doubt I go to see the code with viewvc, and if I still don't get the meaning, I open a bug at bugzilla. No, I don't think translators must download the whole GNOME SVN just to translate. Cheers. -- Jorge González González Weblog: http://aloriel.no-ip.org Fotolog: http://www.flickr.com/photos/aloriel ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
2009/1/6 Sharuzzaman Ahmat Raslan > Hi all, > > I would suggest that GNOME create a tree specifically for translation. > > gnome-po.git should be nice. > > Then translator only need to clone the tree related to translation and > start translating. I often need the source code to check the context or test my translation, not you? I don't understand, how you intend to keep this special tree in sync with the different project branches? If you need a tarball of all po files, it's already possible in DL. There's no real differences for translators in using a VCS or a DVCS (we don't maintain branches or merge from other). It's easy to write a wrapper over any DVCS to checkout/clone/branch and another one to commit/push to fit the translator needs. Maybe someone will take the time to post on this list, the commands to checkout, translate and commit the translation for each DVCS of the survey? Stephane PS: sometimes I also generates the mo file and copy it in a devel distribution (such as Rawhide) to see the result. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: What can Git do for translators?
Hi all,
I would suggest that GNOME create a tree specifically for translation.
gnome-po.git should be nice.
Then translator only need to clone the tree related to translation and start
translating.
After that, he can just send the diff or the whole file via email, or push
it somewhere on the net for GNOME to pull back into the gnome-po.git tree.
It's better if the gnome-po.git tree in GNOME server be made commitable via
SSH by the translator.
Alternatively, use Transifex, which was used by Fedora Project. No need to
learn about git. Just translate :)
On Tue, Jan 6, 2009 at 11:24 PM, Simos Xenitellis <
simos.li...@googlemail.com> wrote:
> Hi All,
>
> There is a discussion on the gnome developer mailing lists regarding a
> possible move
> from Subversion (SVN) to a Distributed Version Control System (DVCS)
> such as git, which is already used for the Linux kernel, Perl, some
> libraries such as clutter.
> This post is to help contribute to the discussion.
>
> If you are a GNOME Foundation member, you probably got a survey e-mail
> in December on the issue.
>
> The survey results are at
> http://blogs.gnome.org/newren/2009/01/03/gnome-dvcs-survey-results/
> http://mces.blogspot.com/2009/01/gnome-dvcs-survey.html
>
> The GNOME dev discussion takes place at
>
> http://mail.gnome.org/archives/desktop-devel-list/2009-January/thread.html#3
> The discussion is somewhat heated, so it's no place for translators to
> post about.
>
> If a move eventually takes place, it will require time and effort, so
> it would not happen within the next six months.
>
> Moving from Subversion (SVN) to a DVCS such as git will have lots of
> benefits for the developers, which is very important. Normally, we
> expect the KDE project to try these things out first but this time it
> appears they are sticking with SVN.
>
> In general, learning a DVCS such as git is a new modern skill. There
> are books available,
> http://book.git-scm.com/ and you can try it out with a free repository
> (100MB) at https://github.com/ or at Gitorious, http://gitorious.org/
>
> The big question is, how would a DVCS affect the GNOME localisation
> workflows?
> Are we going to keep the same easy facilities? Is a DVCS going to make
> some things easier?
> Is there another big project which supports localisation to many
> languages, and it uses a DVCS?
>
> Scenario A
> => Using command line tools, we add a translation to the main repository.
>
> Assume the repository is git://git.gnome.org/gnome-games.git
> we make a local copy by 'cloning' the repository ('checkout' is
> something different in git)
>
> git clone git://git.gnome.org/gnome-games.git
>
> This would create a very big tree, because it would make a full
> offline copy, with all the history for the last ten years or so. When
> we use SVN, a checkout of gnome-games is 124MB. The approximate size
> of a 'git clone' should be quite larger. My test with 'git-svn clone'
> was not conclusive (due to the way it works, it is very slow, I
> stopped after an hour, which it downloaded 74MB).
>
> It might be possible to use the --depth parameter in 'git clone',
> which can limit how far back the history will go to. Reading the man
> page for git-clone, it is not clear if we would be able to 'push' (or
> 'commit' per SVN) the changes back to the tree.
>
> --depth
> Create a shallow clone with a history truncated to the
> specified number of revisions. A shallow repository has a number of
> limitations (you
> cannot clone or fetch from it, nor push from nor into it),
> but is adequate if you are only interested in the recent history of a
> large project
> with a long history, and would want to send in fixes as patches.
>
> Scenario B
> damned-lies and vertimus should be rather easy to convert to git,
> since they would simply need to replace 'svn checkout' with 'git clone
> --depth 0'.
> Is that the case?
>
> Are there any other issues we need to think about?
>
> Simos
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-i18n
>
--
Sharuzzaman Ahmat Raslan
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
What can Git do for translators?
Hi All,
There is a discussion on the gnome developer mailing lists regarding a
possible move
from Subversion (SVN) to a Distributed Version Control System (DVCS)
such as git, which is already used for the Linux kernel, Perl, some
libraries such as clutter.
This post is to help contribute to the discussion.
If you are a GNOME Foundation member, you probably got a survey e-mail
in December on the issue.
The survey results are at
http://blogs.gnome.org/newren/2009/01/03/gnome-dvcs-survey-results/
http://mces.blogspot.com/2009/01/gnome-dvcs-survey.html
The GNOME dev discussion takes place at
http://mail.gnome.org/archives/desktop-devel-list/2009-January/thread.html#3
The discussion is somewhat heated, so it's no place for translators to
post about.
If a move eventually takes place, it will require time and effort, so
it would not happen within the next six months.
Moving from Subversion (SVN) to a DVCS such as git will have lots of
benefits for the developers, which is very important. Normally, we
expect the KDE project to try these things out first but this time it
appears they are sticking with SVN.
In general, learning a DVCS such as git is a new modern skill. There
are books available,
http://book.git-scm.com/ and you can try it out with a free repository
(100MB) at https://github.com/ or at Gitorious, http://gitorious.org/
The big question is, how would a DVCS affect the GNOME localisation workflows?
Are we going to keep the same easy facilities? Is a DVCS going to make
some things easier?
Is there another big project which supports localisation to many
languages, and it uses a DVCS?
Scenario A
=> Using command line tools, we add a translation to the main repository.
Assume the repository is git://git.gnome.org/gnome-games.git
we make a local copy by 'cloning' the repository ('checkout' is
something different in git)
git clone git://git.gnome.org/gnome-games.git
This would create a very big tree, because it would make a full
offline copy, with all the history for the last ten years or so. When
we use SVN, a checkout of gnome-games is 124MB. The approximate size
of a 'git clone' should be quite larger. My test with 'git-svn clone'
was not conclusive (due to the way it works, it is very slow, I
stopped after an hour, which it downloaded 74MB).
It might be possible to use the --depth parameter in 'git clone',
which can limit how far back the history will go to. Reading the man
page for git-clone, it is not clear if we would be able to 'push' (or
'commit' per SVN) the changes back to the tree.
--depth
Create a shallow clone with a history truncated to the
specified number of revisions. A shallow repository has a number of
limitations (you
cannot clone or fetch from it, nor push from nor into it),
but is adequate if you are only interested in the recent history of a
large project
with a long history, and would want to send in fixes as patches.
Scenario B
damned-lies and vertimus should be rather easy to convert to git,
since they would simply need to replace 'svn checkout' with 'git clone
--depth 0'.
Is that the case?
Are there any other issues we need to think about?
Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
