Re: Using Git and separating translations into their own l10n-LL repository
I had been unavailable for some time now and was wondering if there is anything new on this matter about one folder for po files. I've seen new packages making their way to git, which does not work for me yet, but it seems that I'll only change svn commands for git ones. So far all "I" (I am sure that there are many, many useful features for brave profies) gained was 3 new installed packages to make git work. Everything else is the same from my point of view. Thanks. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
Le samedi 04 avril 2009 à 13:56 +0200, Matej Urban a écrit : > I had been unavailable for some time now and was wondering if there is > anything new on this matter about one folder for po files. No, we'll stick with the classical structure. > I've seen new packages making their way to git, which does not work > for me yet, but it seems that I'll only change svn commands for git > ones. So far all "I" (I am sure that there are many, many useful > features for brave profies) gained was 3 new installed packages to > make git work. Everything else is the same from my point of view. All necessary information is here: http://live.gnome.org/TranslationProject/GitHowTo Current modules with translations who have anticipated the git migration are: glib, gnome-scan, gtk+, nemiver, niepce, pitivi, policykit-gnome (broken), and tasks. The remaining modules will migrate just after 2.26.1 (around April 16th). Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
Oh, what is with http://l10n.gnome.org/module/system-tools-backends/ which shows in 2.26. I can not "guess" the correct command. The git clone ssh://usern...@git.gnome.org/git/system-tools-backends returns error. M! ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
Il giorno dom, 05/04/2009 alle 11.03 +0200, Matej Urban ha scritto: > Oh, what is with http://l10n.gnome.org/module/system-tools-backends/ > which shows in 2.26. I can not "guess" the correct command. The git > clone ssh://usern...@git.gnome.org/git/system-tools-backends returns > error. From what I see it is called system-tools-backends-clone on git.gnome.org. Hope it will help you. -- Milo Casagrande signature.asc Description: Questa è una parte del messaggio firmata digitalmente ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
Thanks ~-clone worked! But, how do I only clone the po dir. Whan I enter: clone ssh://usern...@git.gnome.org/git/system-tools-backends-clone/po it returnes error, that dir can not be found! M! 2009/4/5 Milo Casagrande : > Il giorno dom, 05/04/2009 alle 11.03 +0200, Matej Urban ha scritto: >> Oh, what is with http://l10n.gnome.org/module/system-tools-backends/ >> which shows in 2.26. I can not "guess" the correct command. The git >> clone ssh://usern...@git.gnome.org/git/system-tools-backends returns >> error. > > From what I see it is called system-tools-backends-clone on > git.gnome.org. > > Hope it will help you. > > -- > Milo Casagrande > > ___ > 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: Using Git and separating translations into their own l10n-LL repository
Matej Urban ha scritto: Thanks ~-clone worked! But, how do I only clone the po dir. Whan I enter: clone ssh://usern...@git.gnome.org/git/system-tools-backends-clone/po it returnes error, that dir can not be found! If I'm not totally wrong... you can't, you have to clone at least the 'master' branch. But I'm not a git expert. -- Milo Casagrande ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
On Wed, Apr 8, 2009 at 10:04 AM, Milo Casagrande wrote: > Matej Urban ha scritto: >> >> Thanks ~-clone worked! >> But, how do I only clone the po dir. Whan I enter: >> clone ssh://usern...@git.gnome.org/git/system-tools-backends-clone/po >> it returnes error, that dir can not be found! > > If I'm not totally wrong... you can't, you have to clone at least the > 'master' branch. Indeed. You need to clone the (whole) repository and you cannot cherry-pick a subdirectory only, as it was possible with Subversion. There are a few ways around it, and I expect to see them working soon. With damned-lies/vertimus, there is working going on to be able to submit translations through the web interface. In addition, with http://github.com/simos/intltool-manage-vcs/ there is work to automate the retrieving of repositories and committing changes so that the translator is focusing on the actually translation only. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
U ... so much for the thread title. Well, hopefully this will be available soon. I can not afford gigabytes needed to clone all the project of single gnome-?.?? version ... I will try to update latest changes in 2.26 myself, but still; to whom can I send translations for upload before the web interface gets online??? Thanks. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
Le mercredi 08 avril 2009 à 11:33 +0100, Simos a écrit : > On Wed, Apr 8, 2009 at 10:04 AM, Milo Casagrande wrote: > > Matej Urban ha scritto: > >> > >> Thanks ~-clone worked! > >> But, how do I only clone the po dir. Whan I enter: > >> clone ssh://usern...@git.gnome.org/git/system-tools-backends-clone/po > >> it returnes error, that dir can not be found! > > > > If I'm not totally wrong... you can't, you have to clone at least the > > 'master' branch. > > Indeed. You need to clone the (whole) repository > and you cannot cherry-pick a subdirectory only, as it was possible > with Subversion. > > There are a few ways around it, and I expect to see them working soon. > With damned-lies/vertimus, there is working going on to be able to > submit translations > through the web interface. FYI, a ticket asking for a VCS account for damned-lies has been sent to accou...@gnome.org (#8372), end of February. We're now waiting for an answer. Claude > In addition, with http://github.com/simos/intltool-manage-vcs/ there > is work to automate > the retrieving of repositories and committing changes so that the > translator is focusing on > the actually translation only. > > Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
> FYI, a ticket asking for a VCS account for damned-lies has been sent to > accou...@gnome.org (#8372), end of February. We're now waiting for an > answer. > > Claude Eee, was that meant for me? I have no idea what that means. :) M! ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
Le jeudi 09 avril 2009 à 09:37 +0200, Matej Urban a écrit : > > FYI, a ticket asking for a VCS account for damned-lies has been sent to > > accou...@gnome.org (#8372), end of February. We're now waiting for an > > answer. > > > > Claude > > Eee, was that meant for me? I have no idea what that means. :) That was meant for everyone on this list who'd like to know the status of the auto-commit feature of Damned Lies. This feature will enable to commit translations only by uploading final po files on l10n.gnome.org. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
Hello, I tried tu update Slovenian translation for system-tools-backends-clone. It was done successfully, but now I can not "find" the file, cause it did not update the online stats. Can someone check if I placed this file to the correct place? Thanks M! ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
On Thu, Apr 9, 2009 at 4:46 PM, Matej Urban wrote: > Hello, > > I tried tu update Slovenian translation for system-tools-backends-clone. > It was done successfully, but now I can not "find" the file, cause it > did not update the online stats. > > Can someone check if I placed this file to the correct place? The latest commits can be seen at http://git.gnome.org/cgit/system-tools-backends-clone/ I do not see a Slovenian addition. In git, when you commit a change, you need to perform a 'git push' in order for that change to reach the GNOME repository at git.gnome.org. Can you verify that you pushed the change? For more, see http://live.gnome.org/TranslationProject/GitHowTo Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
??? After updating the file I did git commit sl.po -m "Updated Slovenian translation" and git commit LINGUAS sl.po -m "Added sl for Slovenian translation" After that I chacked with git status and it correctly showed # On branch master nothing to commit (working directory clean) There I stopped. If I enter git push I get: ! [rejected]master -> master (non-fast forward) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
On Thu, Apr 9, 2009 at 5:07 PM, Matej Urban wrote: > ??? > > After updating the file I did > git commit sl.po -m "Updated Slovenian translation" > > and > git commit LINGUAS sl.po -m "Added sl for Slovenian translation" > > After that I chacked with git status and it correctly showed > > # On branch master > nothing to commit (working directory clean) > > There I stopped. If I enter git push I get: > ! [rejected] master -> master (non-fast forward) > Okay. You have stumbled on something that is being currently discussed on gnome-infrastructure and we hopefully will have a result to put in the GNOME Localisation GIT HowTo. (see http://mail.gnome.org/archives/gnome-infrastructure/2009-April/msg00031.html) Could you please perform a git pull --rebase and then push your translation? The above command will update your local repository and keep at the same time your translation so you can push it. Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
Hi Simos,
Great explanation, a couple of questions:
- There would be any way to have in a single folder the code and
translations (aka, the way is right now)? There are some translators
(I'm counting in) that likes to have the code also.
- The same concern about maintainers forgetting to git pull(?)
translators is expanded, now they should git pull(?) every single git
repository (if 160 languages, 160 git pulls(?) before each release).
Also, if the new DL will have commit functionality (maybe in half a
year, Claude ... :) and then *all* translations will be committed this
way, wouldn't be overkill to have all this system?
I mean, if it's a temporal situation that, shouldn't be more productive
to instead of "wasting" time doing this git submodule thing to provide
resources and time to get commit functionality to DL that seems to be
more desired by translators (that's my guess no data actually, just
supposed so my arguments seems better :D).
Cheers,
El dt 13 de 01 de 2009 a les 23:01 +, en/na Simos Xenitellis va
escriure:
> Hi All,
>
> This is a long-ish post regarding the migration to Git and
> what we can do to make l10n a bit better.
>
> Here I suggest to use the 'git submodule' support
> so that the translation material for each language
> reside in a single repository.
> Comments would be appreciated.
> If all is fine, I'll put this, with more details, to live.gnome.org.
>
> When splitting the l10n files from each module, there is a choice to either
> 1. create a companion repository for each module (for example, for
> mousetweaks, create 'mousetweaks-l10n')
> that will hold all localisation files for all languages, for this module.
> If we have 1000 modules, there would be 1000 additional companion l10n
> modules.
> 2. create a repository for each language, and this repository will
> contain all localisation files for all modules.
> If we have 1000 modules, there would be just 160 additional l10n
> repositories (it's one new repository per language).
>
> The right choice appears to be to create one repository per language.
> There are many reasons which can be discussed if deemed necessary.
>
> The rest of the e-mail shows how the separated repositories look like.
> I used as an example the mousetweaks and vinagre modules, for the el,
> es, fr and sv languages.
> Both have help/ and po/ subdirectories with l10n material.
> You can fork the generated (six) repositories from
> http://github.com/simos/ if you want to try them out.
>
> STRUCTURE (l10n-LL)
> A language repository name is of the form 'l10n-LL', where LL is the
> ISO 639 (-123) language code as usual.
> Inside 'l10n-LL' there are directories per module (with the module
> name), and further subdirectories 'po/' and 'help/' as necessary.
> For example,
>
> l10n-el
> ├─ mousetweaks
> │ ├─ help
> │ │ └─ el
> │ │ └─ el.po
> │ └─ po
> │ └─ el.po
> └─ vinagre
> ├─ help
> │ └─ el
> │ └─ el.po
> └─ po
> └─ el.po
>
> and
>
> l10n-es
> ├─ mousetweaks
> │ ├─ help
> │ │ └─ es
> │ │ ├─ es.po
> │ │ └─ figures
> │ │ ├─ mouse-a11y-add-applet-to-panel-window.png
> │ │ ├─ mouse-a11y-dwell-checkbox.png
> │ │ ├─ mouse-a11y-dwell-click-type-applet.png
> │ │ ├─ mouse-a11y-dwell-click-type-window.png
> │ │ ├─ mouse-a11y-dwell-ctw-checkbox.png
> │ │ ├─ mouse-a11y-dwell-delay-slider.png
> │ │ ├─ mouse-a11y-dwell-gesture-mapping.png
> │ │ ├─ mouse-a11y-dwell-mode-choice.png
> │ │ ├─ mouse-a11y-dwell-motion-treshold.png
> │ │ ├─ mouse-a11y-pointer-capture-context-menu.png
> │ │ ├─ mouse-a11y-pointer-capture-locked.png
> │ │ ├─ mouse-a11y-pointer-capture-preferences.png
> │ │ ├─ mouse-a11y-ssc-checkbox.png
> │ │ ├─ mouse-a11y-ssc-delay-slider.png
> │ │ └─ mouse-a11y-tab.png
> │ └─ po
> │ └─ es.po
> └─ vinagre
> ├─ help
> │ └─ es
> │ ├─ es.po
> │ └─ figures
> │ └─ vinagre-screenshot.png
> └─ po
> └─ es.po
>
> STRUCTURE ('l10n' supermodule)
> Per git parlance, we create a 'l10n' supermodule, and inside it we add
> each language repository as submodules.
> Thus,
>
> l10n
> ├─ README
> ├─ l10n-el/
> ├─ l10n-es/
> ├─ l10n-fr/
> └─ l10n-sv/
>
> The above graphic shows the first level of directories.
> When we add a new language, the l10n coordinators will add a new entry
> here to the new repository 'l10n-LL'.
> Each 'l10n-LL' entry is added with 'git submodule add', and points to
> a repository created earlier.
>
> STRUCTURE (module)
> Now, each module (such as mousetweaks and vinagre) need to simply add
> the 'l10n' supermodule.
> We remove from help/ and po/ all *.po and figures/ files. For our two
> modules, the po/ and help/ subdirectories would look like
>
> mousetweak:
> po
> ├─ LINGUAS
> ├─ POTFILES.in
> └─ POTFILES.skip
> help
>
Re: Using Git and separating translations into their own l10n-LL repository
On Tue, Jan 13, 2009 at 11:31 PM, Gil Forcada wrote: > Hi Simos, > > Great explanation, a couple of questions: > > - There would be any way to have in a single folder the code and > translations (aka, the way is right now)? There are some translators > (I'm counting in) that likes to have the code also. I am not sure which module you have in mind. I would say that the idea is, if the translation files are expected to be managed by damned-lies/l10n.gnome.org, they should reside in the l10n-LL submodule. > - The same concern about maintainers forgetting to git pull(?) > translators is expanded, now they should git pull(?) every single git > repository (if 160 languages, 160 git pulls(?) before each release). The 'git submodule update' command, when you run in from the 'l10n' supermodule, pulls all the l10n-LL repositories automatically by default. There is an option to 'git submodule update' to pull individual language repositories as well. > Also, if the new DL will have commit functionality (maybe in half a > year, Claude ... :) and then *all* translations will be committed this > way, wouldn't be overkill to have all this system? > > I mean, if it's a temporal situation that, shouldn't be more productive > to instead of "wasting" time doing this git submodule thing to provide > resources and time to get commit functionality to DL that seems to be > more desired by translators (that's my guess no data actually, just > supposed so my arguments seems better :D). I would consider that separating code from localisation files would be a fundamental improvement rather than a temporary solution. The issue of manpower to make such changes is the main disadvantage. It would be easier to provide commit support to damned-lies when we have separated l10n-LL repositories. Damned-lies would 'auto'-commit only to designated repositories. I do not know the details of the SVN hooks and damned-lies. I think that if a commit/push to a project would call a hook that would invoke 'intltool-update -P' (create POT template file) and store it somewhere, then damned-lies would not need to clone locally any other GNOME modules. To add a few more advantages, 1. Can add access controls for translators to the l10n-LL repositories. 2. It allows translators to make changes across all translations (for example, change 'widget' in all my translations of GNOME). 3. Pootle could be adapted to perform easier GNOME translation marathons. 4. GTranslator could work as KBabel, it would clone the l10n-LL repository and would be able to show all translations in a huge sorted list. This way, similar translations can be easily identified. > > El dt 13 de 01 de 2009 a les 23:01 +, en/na Simos Xenitellis va > escriure: >> Hi All, >> >> This is a long-ish post regarding the migration to Git and >> what we can do to make l10n a bit better. >> >> Here I suggest to use the 'git submodule' support >> so that the translation material for each language >> reside in a single repository. >> Comments would be appreciated. >> If all is fine, I'll put this, with more details, to live.gnome.org. >> >> When splitting the l10n files from each module, there is a choice to either >> 1. create a companion repository for each module (for example, for >> mousetweaks, create 'mousetweaks-l10n') >> that will hold all localisation files for all languages, for this module. >> If we have 1000 modules, there would be 1000 additional companion l10n >> modules. >> 2. create a repository for each language, and this repository will >> contain all localisation files for all modules. >> If we have 1000 modules, there would be just 160 additional l10n >> repositories (it's one new repository per language). >> >> The right choice appears to be to create one repository per language. >> There are many reasons which can be discussed if deemed necessary. >> >> The rest of the e-mail shows how the separated repositories look like. >> I used as an example the mousetweaks and vinagre modules, for the el, >> es, fr and sv languages. >> Both have help/ and po/ subdirectories with l10n material. >> You can fork the generated (six) repositories from >> http://github.com/simos/ if you want to try them out. >> >> STRUCTURE (l10n-LL) >> A language repository name is of the form 'l10n-LL', where LL is the >> ISO 639 (-123) language code as usual. >> Inside 'l10n-LL' there are directories per module (with the module >> name), and further subdirectories 'po/' and 'help/' as necessary. >> For example, >> >> l10n-el >> ├─ mousetweaks >> │ ├─ help >> │ │ └─ el >> │ │ └─ el.po >> │ └─ po >> │ └─ el.po >> └─ vinagre >> ├─ help >> │ └─ el >> │ └─ el.po >> └─ po >> └─ el.po >> >> and >> >> l10n-es >> ├─ mousetweaks >> │ ├─ help >> │ │ └─ es >> │ │ ├─ es.po >> │ │ └─ figures >> │ │ ├─ mouse-a11y-add-applet-to-panel-window.png >> │ │ ├─ mouse-a11y-dwell-checkbox.png >> │ │ ├─ mouse-a11
Re: Using Git and separating translations into their own l10n-LL repository
El dc 14 de 01 de 2009 a les 00:42 +, en/na Simos Xenitellis va escriure: > On Tue, Jan 13, 2009 at 11:31 PM, Gil Forcada wrote: > > Hi Simos, > > > > Great explanation, a couple of questions: > > > > - There would be any way to have in a single folder the code and > > translations (aka, the way is right now)? There are some translators > > (I'm counting in) that likes to have the code also. > > I am not sure which module you have in mind. Sorry, I wasn't really clear. I meant to keep like it is now with code and translations together. > I would say that the idea is, if the translation files are expected to > be managed by damned-lies/l10n.gnome.org, they should reside in the > l10n-LL submodule. > > > - The same concern about maintainers forgetting to git pull(?) > > translators is expanded, now they should git pull(?) every single git > > repository (if 160 languages, 160 git pulls(?) before each release). > > The 'git submodule update' command, when you run in from the 'l10n' > supermodule, > pulls all the l10n-LL repositories automatically by default. > There is an option to 'git submodule update' to pull individual > language repositories as well. If I understand correctly the repository will be like: l10n - l10n-LL -- evolution --- po LL.po -- eog --- po LL.po ... So if they update the whole l10n module (the top module) they will get all translations from all modules not all translations from their module. Cheers, > > Also, if the new DL will have commit functionality (maybe in half a > > year, Claude ... :) and then *all* translations will be committed this > > way, wouldn't be overkill to have all this system? > > > > I mean, if it's a temporal situation that, shouldn't be more productive > > to instead of "wasting" time doing this git submodule thing to provide > > resources and time to get commit functionality to DL that seems to be > > more desired by translators (that's my guess no data actually, just > > supposed so my arguments seems better :D). > > I would consider that separating code from localisation files would be > a fundamental improvement rather than a temporary solution. > The issue of manpower to make such changes is the main disadvantage. > > It would be easier to provide commit support to damned-lies when > we have separated l10n-LL repositories. Damned-lies would 'auto'-commit > only to designated repositories. > > I do not know the details of the SVN hooks and damned-lies. I think > that if a commit/push to a project would call a hook that would invoke > 'intltool-update -P' (create POT template file) and store it > somewhere, then damned-lies would not need to clone locally any other > GNOME modules. > > To add a few more advantages, > 1. Can add access controls for translators to the l10n-LL repositories. > 2. It allows translators to make changes across all translations (for > example, change 'widget' in all my translations of GNOME). > 3. Pootle could be adapted to perform easier GNOME translation marathons. > 4. GTranslator could work as KBabel, it would clone the l10n-LL > repository and would be able to show all translations in a huge sorted > list. This way, similar translations can be easily identified. > > > > > El dt 13 de 01 de 2009 a les 23:01 +, en/na Simos Xenitellis va > > escriure: > >> Hi All, > >> > >> This is a long-ish post regarding the migration to Git and > >> what we can do to make l10n a bit better. > >> > >> Here I suggest to use the 'git submodule' support > >> so that the translation material for each language > >> reside in a single repository. > >> Comments would be appreciated. > >> If all is fine, I'll put this, with more details, to live.gnome.org. > >> > >> When splitting the l10n files from each module, there is a choice to either > >> 1. create a companion repository for each module (for example, for > >> mousetweaks, create 'mousetweaks-l10n') > >> that will hold all localisation files for all languages, for this module. > >> If we have 1000 modules, there would be 1000 additional companion l10n > >> modules. > >> 2. create a repository for each language, and this repository will > >> contain all localisation files for all modules. > >> If we have 1000 modules, there would be just 160 additional l10n > >> repositories (it's one new repository per language). > >> > >> The right choice appears to be to create one repository per language. > >> There are many reasons which can be discussed if deemed necessary. > >> > >> The rest of the e-mail shows how the separated repositories look like. > >> I used as an example the mousetweaks and vinagre modules, for the el, > >> es, fr and sv languages. > >> Both have help/ and po/ subdirectories with l10n material. > >> You can fork the generated (six) repositories from > >> http://github.com/simos/ if you want to try them out. > >> > >> STRUCTURE (l10n-LL) > >> A language repository name is of the form 'l10n-LL', where LL is the > >> ISO 639 (-123) language code as usual
Re: Using Git and separating translations into their own l10n-LL repository
On Wed, Jan 14, 2009 at 3:34 PM, Gil Forcada wrote: > El dc 14 de 01 de 2009 a les 00:42 +, en/na Simos Xenitellis va > escriure: >> On Tue, Jan 13, 2009 at 11:31 PM, Gil Forcada wrote: >> > Hi Simos, >> > >> > Great explanation, a couple of questions: >> > >> > - There would be any way to have in a single folder the code and >> > translations (aka, the way is right now)? There are some translators >> > (I'm counting in) that likes to have the code also. >> >> I am not sure which module you have in mind. > > Sorry, I wasn't really clear. I meant to keep like it is now with code > and translations together. > >> I would say that the idea is, if the translation files are expected to >> be managed by damned-lies/l10n.gnome.org, they should reside in the >> l10n-LL submodule. >> >> > - The same concern about maintainers forgetting to git pull(?) >> > translators is expanded, now they should git pull(?) every single git >> > repository (if 160 languages, 160 git pulls(?) before each release). >> >> The 'git submodule update' command, when you run in from the 'l10n' >> supermodule, >> pulls all the l10n-LL repositories automatically by default. >> There is an option to 'git submodule update' to pull individual >> language repositories as well. > > If I understand correctly the repository will be like: > l10n > - l10n-LL > -- evolution > --- po > LL.po > -- eog > --- po > LL.po > ... > > So if they update the whole l10n module (the top module) they will get > all translations from all modules not all translations from their > module. Indeed, that is an issue. I did not find an easy way so that the 'l10n' tree can stay outside the repositories, and each module would have a symbolic link towards 'l10n'. That is, mousetweaks ├─ l10n (link to ../l10n) │... In addition to this, there is the issue with branching; all modules in a GNOME release should branch at the same time, and have a standard common branch name. Cheers, Simos > >> > Also, if the new DL will have commit functionality (maybe in half a >> > year, Claude ... :) and then *all* translations will be committed this >> > way, wouldn't be overkill to have all this system? >> > >> > I mean, if it's a temporal situation that, shouldn't be more productive >> > to instead of "wasting" time doing this git submodule thing to provide >> > resources and time to get commit functionality to DL that seems to be >> > more desired by translators (that's my guess no data actually, just >> > supposed so my arguments seems better :D). >> >> I would consider that separating code from localisation files would be >> a fundamental improvement rather than a temporary solution. >> The issue of manpower to make such changes is the main disadvantage. >> >> It would be easier to provide commit support to damned-lies when >> we have separated l10n-LL repositories. Damned-lies would 'auto'-commit >> only to designated repositories. >> >> I do not know the details of the SVN hooks and damned-lies. I think >> that if a commit/push to a project would call a hook that would invoke >> 'intltool-update -P' (create POT template file) and store it >> somewhere, then damned-lies would not need to clone locally any other >> GNOME modules. >> >> To add a few more advantages, >> 1. Can add access controls for translators to the l10n-LL repositories. >> 2. It allows translators to make changes across all translations (for >> example, change 'widget' in all my translations of GNOME). >> 3. Pootle could be adapted to perform easier GNOME translation marathons. >> 4. GTranslator could work as KBabel, it would clone the l10n-LL >> repository and would be able to show all translations in a huge sorted >> list. This way, similar translations can be easily identified. >> >> > >> > El dt 13 de 01 de 2009 a les 23:01 +, en/na Simos Xenitellis va >> > escriure: >> >> Hi All, >> >> >> >> This is a long-ish post regarding the migration to Git and >> >> what we can do to make l10n a bit better. >> >> >> >> Here I suggest to use the 'git submodule' support >> >> so that the translation material for each language >> >> reside in a single repository. >> >> Comments would be appreciated. >> >> If all is fine, I'll put this, with more details, to live.gnome.org. >> >> >> >> When splitting the l10n files from each module, there is a choice to >> >> either >> >> 1. create a companion repository for each module (for example, for >> >> mousetweaks, create 'mousetweaks-l10n') >> >> that will hold all localisation files for all languages, for this module. >> >> If we have 1000 modules, there would be 1000 additional companion l10n >> >> modules. >> >> 2. create a repository for each language, and this repository will >> >> contain all localisation files for all modules. >> >> If we have 1000 modules, there would be just 160 additional l10n >> >> repositories (it's one new repository per language). >> >> >> >> The right choice appears to be to create one repository per language. >> >> There are
Re: Using Git and separating translations into their own l10n-LL repository
Le mardi 13 janvier 2009 à 23:01 +, Simos Xenitellis a écrit : > Hi All, > > This is a long-ish post regarding the migration to Git and > what we can do to make l10n a bit better. > > Here I suggest to use the 'git submodule' support > so that the translation material for each language > reside in a single repository. > Comments would be appreciated. > If all is fine, I'll put this, with more details, to live.gnome.org. Thanks Simos for taking the time to evaluate such an infrastructure for l10n. However I doubt the relative complexity implied by your solution is worth the trouble. I see basically two use cases: 1. The non-technical coordinator, who would like the simplest infrastructure to commit his translation files. -> In this case, an auto-commit feature integrated in damned-lies is the best solution. No (D)VCS knowledge is required for him. FYI I've already tested a prototype which can do this in the testbed git infrastructure. 2. The geek coordinator who like to have the most control on what he's doing and how he do it. -> IMHO, this one won't mind checking out entire git modules. This is not very much different than the current situation. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
On 1/15/09, Claude Paroz wrote: > Le mardi 13 janvier 2009 à 23:01 +, Simos Xenitellis a écrit : > > This is a long-ish post regarding the migration to Git and > > what we can do to make l10n a bit better. > > > > Here I suggest to use the 'git submodule' support > > so that the translation material for each language > > reside in a single repository. > > Comments would be appreciated. > > If all is fine, I'll put this, with more details, to live.gnome.org. > > > > Thanks Simos for taking the time to evaluate such an infrastructure for > l10n. > However I doubt the relative complexity implied by your solution is > worth the trouble. I see basically two use cases: > > 1. The non-technical coordinator, who would like the simplest > infrastructure to commit his translation files. > > -> In this case, an auto-commit feature integrated in damned-lies is the > best solution. No (D)VCS knowledge is required for him. FYI I've already > tested a prototype which can do this in the testbed git infrastructure. > > > 2. The geek coordinator who like to have the most control on what he's > doing and how he do it. > > -> IMHO, this one won't mind checking out entire git modules. This is > not very much different than the current situation. FWIW, I fully agree with Claude here. Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
El dv 16 de 01 de 2009 a les 01:42 +0100, en/na Christian Rose va escriure: > On 1/15/09, Claude Paroz wrote: > > Le mardi 13 janvier 2009 à 23:01 +, Simos Xenitellis a écrit : > > > This is a long-ish post regarding the migration to Git and > > > what we can do to make l10n a bit better. > > > > > > Here I suggest to use the 'git submodule' support > > > so that the translation material for each language > > > reside in a single repository. > > > Comments would be appreciated. > > > If all is fine, I'll put this, with more details, to live.gnome.org. > > > > > > > > Thanks Simos for taking the time to evaluate such an infrastructure for > > l10n. > > However I doubt the relative complexity implied by your solution is > > worth the trouble. I see basically two use cases: > > > > 1. The non-technical coordinator, who would like the simplest > > infrastructure to commit his translation files. > > > > -> In this case, an auto-commit feature integrated in damned-lies is the > > best solution. No (D)VCS knowledge is required for him. FYI I've already > > tested a prototype which can do this in the testbed git infrastructure. > > > > > > 2. The geek coordinator who like to have the most control on what he's > > doing and how he do it. > > > > -> IMHO, this one won't mind checking out entire git modules. This is > > not very much different than the current situation. > > FWIW, I fully agree with Claude here. +1 also :) > Christian > ___ > 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: Using Git and separating translations into their own l10n-LL repository
2009/1/16 Gil Forcada : > > El dv 16 de 01 de 2009 a les 01:42 +0100, en/na Christian Rose va > escriure: >> On 1/15/09, Claude Paroz wrote: >> > Le mardi 13 janvier 2009 à 23:01 +, Simos Xenitellis a écrit : >> > > This is a long-ish post regarding the migration to Git and >> > > what we can do to make l10n a bit better. >> > > >> > > Here I suggest to use the 'git submodule' support >> > > so that the translation material for each language >> > > reside in a single repository. >> > > Comments would be appreciated. >> > > If all is fine, I'll put this, with more details, to live.gnome.org. >> > >> > >> > >> > Thanks Simos for taking the time to evaluate such an infrastructure for >> > l10n. >> > However I doubt the relative complexity implied by your solution is >> > worth the trouble. I see basically two use cases: >> > >> > 1. The non-technical coordinator, who would like the simplest >> > infrastructure to commit his translation files. >> > >> > -> In this case, an auto-commit feature integrated in damned-lies is the >> > best solution. No (D)VCS knowledge is required for him. FYI I've already >> > tested a prototype which can do this in the testbed git infrastructure. >> > >> > >> > 2. The geek coordinator who like to have the most control on what he's >> > doing and how he do it. >> > >> > -> IMHO, this one won't mind checking out entire git modules. This is >> > not very much different than the current situation. >> >> FWIW, I fully agree with Claude here. > > +1 also :) And a +1 from me. > >> Christian >> ___ >> 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 > ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
On Sat, Jan 17, 2009 at 6:39 PM, Kenneth Nielsen wrote: > 2009/1/16 Gil Forcada : >> >> El dv 16 de 01 de 2009 a les 01:42 +0100, en/na Christian Rose va >> escriure: >>> On 1/15/09, Claude Paroz wrote: >>> > Le mardi 13 janvier 2009 à 23:01 +, Simos Xenitellis a écrit : >>> > > This is a long-ish post regarding the migration to Git and >>> > > what we can do to make l10n a bit better. >>> > > >>> > > Here I suggest to use the 'git submodule' support >>> > > so that the translation material for each language >>> > > reside in a single repository. >>> > > Comments would be appreciated. >>> > > If all is fine, I'll put this, with more details, to live.gnome.org. >>> > >>> > >>> > >>> > Thanks Simos for taking the time to evaluate such an infrastructure for >>> > l10n. >>> > However I doubt the relative complexity implied by your solution is >>> > worth the trouble. I see basically two use cases: >>> > >>> > 1. The non-technical coordinator, who would like the simplest >>> > infrastructure to commit his translation files. >>> > >>> > -> In this case, an auto-commit feature integrated in damned-lies is the >>> > best solution. No (D)VCS knowledge is required for him. FYI I've already >>> > tested a prototype which can do this in the testbed git infrastructure. >>> > >>> > >>> > 2. The geek coordinator who like to have the most control on what he's >>> > doing and how he do it. >>> > >>> > -> IMHO, this one won't mind checking out entire git modules. This is >>> > not very much different than the current situation. >>> >>> FWIW, I fully agree with Claude here. >> >> +1 also :) > > And a +1 from me. OK, let's summarize for future reference and close the thread. One of the issues to try to split translation files from the rest of the modules is because a 'git clone' downloads the full history of a repository, compared to a 'svn checkout' which downloads just a snapshot. In addition, svn can also checkout a subdirectory of a repository, something that git cannot do. Separating the repositories in code and translations using 'git submodule' would add too much effort in terms of updating the tools, and changing the practices that translators would use to maintain the translations. It is easier to keep as is. In terms of disk space, a 'git clone' is surprisingly very economic, almost matching an 'svn checkout'. In terms of speed when cloning a repository, git is more CPU intensive for the GIT server, and is slower than a 'svn checkout'. It would make sense for translators to dedicate some space so that cloned repositories are kept locally (instead of erasing them). Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
There isn't an option (I have read it somewhere, sorry for bad references) that tells git to only download the last version and not the full history? Cheers, El dg 18 de 01 de 2009 a les 00:01 +, en/na Simos Xenitellis va escriure: > On Sat, Jan 17, 2009 at 6:39 PM, Kenneth Nielsen > wrote: > > 2009/1/16 Gil Forcada : > >> > >> El dv 16 de 01 de 2009 a les 01:42 +0100, en/na Christian Rose va > >> escriure: > >>> On 1/15/09, Claude Paroz wrote: > >>> > Le mardi 13 janvier 2009 à 23:01 +, Simos Xenitellis a écrit : > >>> > > This is a long-ish post regarding the migration to Git and > >>> > > what we can do to make l10n a bit better. > >>> > > > >>> > > Here I suggest to use the 'git submodule' support > >>> > > so that the translation material for each language > >>> > > reside in a single repository. > >>> > > Comments would be appreciated. > >>> > > If all is fine, I'll put this, with more details, to live.gnome.org. > >>> > > >>> > > >>> > > >>> > Thanks Simos for taking the time to evaluate such an infrastructure for > >>> > l10n. > >>> > However I doubt the relative complexity implied by your solution is > >>> > worth the trouble. I see basically two use cases: > >>> > > >>> > 1. The non-technical coordinator, who would like the simplest > >>> > infrastructure to commit his translation files. > >>> > > >>> > -> In this case, an auto-commit feature integrated in damned-lies is > >>> > the > >>> > best solution. No (D)VCS knowledge is required for him. FYI I've > >>> > already > >>> > tested a prototype which can do this in the testbed git infrastructure. > >>> > > >>> > > >>> > 2. The geek coordinator who like to have the most control on what he's > >>> > doing and how he do it. > >>> > > >>> > -> IMHO, this one won't mind checking out entire git modules. This is > >>> > not very much different than the current situation. > >>> > >>> FWIW, I fully agree with Claude here. > >> > >> +1 also :) > > > > And a +1 from me. > > OK, let's summarize for future reference and close the thread. > > One of the issues to try to split translation files from the rest of > the modules is because a 'git clone' downloads the full history of a > repository, compared to a 'svn checkout' which downloads just a > snapshot. In addition, svn can also checkout a subdirectory of a > repository, something that git cannot do. > > Separating the repositories in code and translations using 'git > submodule' would add too much effort in terms of updating the tools, > and changing the practices that translators would use to maintain the > translations. It is easier to keep as is. > > In terms of disk space, a 'git clone' is surprisingly very economic, > almost matching an 'svn checkout'. > In terms of speed when cloning a repository, git is more CPU intensive > for the GIT server, and is slower than a 'svn checkout'. > It would make sense for translators to dedicate some space so that > cloned repositories are kept locally (instead of erasing them). > > 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: Using Git and separating translations into their own l10n-LL repository
On Sun, Jan 18, 2009 at 9:55 AM, Gil Forcada wrote: > There isn't an option (I have read it somewhere, sorry for bad > references) that tells git to only download the last version and not the > full history? There is an option '--depth 1' that you can use when you clone a repository. Depending on the module, I noticed it gives up to moderate time and space improvements. git.gnome.org is now down, so I tried with git://anongit.freedesktop.org/git/xorg/xserver Clone: 1.43 min, objects 26.19 MiB, directory size 55MB Shallow clone: 50s, objects 16.22 MiB, directory size 43MB I also tried with the Linux kernel, git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Clone: 9.10min, objects 258.23 MiB, directory size 660MB Shallow clone: 5.38min, objects 152.34 MiB, directory size 531MB When cloning, the 'Receiving objects' stage is the one that takes most of the time and refers to compressed data. I suppose it is a good indication of the total time. When I tried the other day with git.gnome.org, I noticed much slower times. It appears the reason is that git.gnome.org (test server) was very slow when I tried it, achieving up to 100KB/s at best. With X.Org and the Linux kernel, the speed was most of the time at 800KB/s. In addition, the 'git clone' man page mentions "--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." It says that you cannot "push from [a shallow clone]", which means that a translator would not be able to push a translation from a shallow clone. I tried with a small repository where I have push access and I was able to push a commit from a shallow clone to the git server. This may be some feature on GitHub; all Google searches for 'shallow clone' repeat that you cannot push your changes from your shallow clone. It would be important to try this one out on git.gnome.org, when it is available. Simos > Cheers, > > El dg 18 de 01 de 2009 a les 00:01 +, en/na Simos Xenitellis va > escriure: >> On Sat, Jan 17, 2009 at 6:39 PM, Kenneth Nielsen >> wrote: >> > 2009/1/16 Gil Forcada : >> >> >> >> El dv 16 de 01 de 2009 a les 01:42 +0100, en/na Christian Rose va >> >> escriure: >> >>> On 1/15/09, Claude Paroz wrote: >> >>> > Le mardi 13 janvier 2009 à 23:01 +, Simos Xenitellis a écrit : >> >>> > > This is a long-ish post regarding the migration to Git and >> >>> > > what we can do to make l10n a bit better. >> >>> > > >> >>> > > Here I suggest to use the 'git submodule' support >> >>> > > so that the translation material for each language >> >>> > > reside in a single repository. >> >>> > > Comments would be appreciated. >> >>> > > If all is fine, I'll put this, with more details, to live.gnome.org. >> >>> > >> >>> > >> >>> > >> >>> > Thanks Simos for taking the time to evaluate such an infrastructure >> >>> > for >> >>> > l10n. >> >>> > However I doubt the relative complexity implied by your solution is >> >>> > worth the trouble. I see basically two use cases: >> >>> > >> >>> > 1. The non-technical coordinator, who would like the simplest >> >>> > infrastructure to commit his translation files. >> >>> > >> >>> > -> In this case, an auto-commit feature integrated in damned-lies is >> >>> > the >> >>> > best solution. No (D)VCS knowledge is required for him. FYI I've >> >>> > already >> >>> > tested a prototype which can do this in the testbed git >> >>> > infrastructure. >> >>> > >> >>> > >> >>> > 2. The geek coordinator who like to have the most control on what he's >> >>> > doing and how he do it. >> >>> > >> >>> > -> IMHO, this one won't mind checking out entire git modules. This is >> >>> > not very much different than the current situation. >> >>> >> >>> FWIW, I fully agree with Claude here. >> >> >> >> +1 also :) >> > >> > And a +1 from me. >> >> OK, let's summarize for future reference and close the thread. >> >> One of the issues to try to split translation files from the rest of >> the modules is because a 'git clone' downloads the full history of a >> repository, compared to a 'svn checkout' which downloads just a >> snapshot. In addition, svn can also checkout a subdirectory of a >> repository, something that git cannot do. >> >> Separating the repositories in code and translations using 'git >> submodule' would add too much effort in terms of updating the tools, >> and changing the practices that translators would use to maintain the >> translations. It is easier to keep as is. >> >> In terms of disk space, a 'git clone' is surprisingly very economic, >> almost matching an 'svn checkout'. >> In terms of speed when cloning a repository, git is more CPU intensive >> for the GIT server, and is slower than a 'svn checkout'. >> It wo
Re: Using Git and separating translations into their own l10n-LL repository
Hello, I'm really trying to understand the changes. The title sais: Using Git and separating translations into their own l10n-LL repository The title implies that ALL and ONLY po files from ALL the languages UI and HELP will fall into "l10n-LL" repository, but that will not be the case, as I understand. I really don't know why this is so unpopular among developers. I posted a bug http://bugzilla.gnome.org/show_bug.cgi?id=554257 and also a reminder that I don't fill-in the changelog entries. I can not find those great "scripts" in the gnome archive, that will do all the work in my place, nor can I write one, so doing it step by step is the only way I know. It takes TOO much time, TOO much bandwidth and TOO much space to maintain the language. Putting/linking/sync all po files in one single dir solves many problems for coords like myself. Please, guys, check again if there is a way to do that. Last coordinator dropped out of the translation game because this updating took too much of everything, especially his time. Matej ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
Hi, Actually a lot has changed: - for advanced-translators the same workflow will be maintained. - for plain translators a web interface to commit languages will be provided. So I think you fall in the second option and thus you will need to have access to http://l10n.gnome.org to download updated po files (like you can do right know), track its status (like as of January you can do right now) and commit them in source repositories (like you will be able to do in a not-so-distant-future, Claude said it has a beta working version that does this, I'm right Claude?) So, all in all, your workflow will be a lot improved since you will only have to download and upload files from/to http://l10n.gnome.org :) Hope I haven't said any lie! Cheers, El dl 19 de 01 de 2009 a les 13:38 +0100, en/na Matej Urban va escriure: > Hello, > > I'm really trying to understand the changes. The title sais: > Using Git and separating translations into their own l10n-LL repository > > The title implies that ALL and ONLY po files from ALL the languages UI > and HELP will fall into "l10n-LL" repository, but that will not be the > case, as I understand. I really don't know why this is so unpopular > among developers. > > I posted a bug http://bugzilla.gnome.org/show_bug.cgi?id=554257 and > also a reminder that I don't fill-in the changelog entries. I can not > find those great "scripts" in the gnome archive, that will do all the > work in my place, nor can I write one, so doing it step by step is the > only way I know. It takes TOO much time, TOO much bandwidth and TOO > much space to maintain the language. Putting/linking/sync all po files > in one single dir solves many problems for coords like myself. > > Please, guys, check again if there is a way to do that. Last > coordinator dropped out of the translation game because this updating > took too much of everything, especially his time. > > Matej -- 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: Using Git and separating translations into their own l10n-LL repository
Le lundi 19 janvier 2009 à 13:38 +0100, Matej Urban a écrit : > Hello, > > I'm really trying to understand the changes. The title sais: > Using Git and separating translations into their own l10n-LL repository > > The title implies that ALL and ONLY po files from ALL the languages UI > and HELP will fall into "l10n-LL" repository, but that will not be the > case, as I understand. I really don't know why this is so unpopular > among developers. > > I posted a bug http://bugzilla.gnome.org/show_bug.cgi?id=554257 and > also a reminder that I don't fill-in the changelog entries. I can not > find those great "scripts" in the gnome archive, that will do all the > work in my place, nor can I write one, so doing it step by step is the > only way I know. It takes TOO much time, TOO much bandwidth and TOO > much space to maintain the language. Putting/linking/sync all po files > in one single dir solves many problems for coords like myself. > > Please, guys, check again if there is a way to do that. Last > coordinator dropped out of the translation game because this updating > took too much of everything, especially his time. The intended future workflow is the following : - find and download po file on l10n.gnome.org - translate the file locally - upload the file on l10n.gnome.org Nothing more. We're very close to such a solution with the current damned-lies code. I may event try to implement this workflow with current SVN infrastructure if I find enough time. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
Thanks, Gil, I will wait and see, but since I'm a translator/mantainer and since I doubt I will be able to upload many files at once, the only difference so far I see, is that I will replace keyboard keystrokes for mouse clicks. There will be no changelog, which is an improvement :) Anyhow, in the end I will use whatever I'll need to do it, but keep nagging about it. For some reason, I really doubt that single dir for all po files, is a big programing deal. No obsolete clicks, no hassle, just pure translation work. Matej On Mon, Jan 19, 2009 at 1:46 PM, Gil Forcada wrote: > Hi, > > Actually a lot has changed: > > - for advanced-translators the same workflow will be maintained. > - for plain translators a web interface to commit languages will be > provided. > > So I think you fall in the second option and thus you will need to have > access to http://l10n.gnome.org to download updated po files (like you > can do right know), track its status (like as of January you can do > right now) and commit them in source repositories (like you will be able > to do in a not-so-distant-future, Claude said it has a beta working > version that does this, I'm right Claude?) > > So, all in all, your workflow will be a lot improved since you will only > have to download and upload files from/to http://l10n.gnome.org :) > > Hope I haven't said any lie! > > Cheers, > > El dl 19 de 01 de 2009 a les 13:38 +0100, en/na Matej Urban va escriure: >> Hello, >> >> I'm really trying to understand the changes. The title sais: >> Using Git and separating translations into their own l10n-LL repository >> >> The title implies that ALL and ONLY po files from ALL the languages UI >> and HELP will fall into "l10n-LL" repository, but that will not be the >> case, as I understand. I really don't know why this is so unpopular >> among developers. >> >> I posted a bug http://bugzilla.gnome.org/show_bug.cgi?id=554257 and >> also a reminder that I don't fill-in the changelog entries. I can not >> find those great "scripts" in the gnome archive, that will do all the >> work in my place, nor can I write one, so doing it step by step is the >> only way I know. It takes TOO much time, TOO much bandwidth and TOO >> much space to maintain the language. Putting/linking/sync all po files >> in one single dir solves many problems for coords like myself. >> >> Please, guys, check again if there is a way to do that. Last >> coordinator dropped out of the translation game because this updating >> took too much of everything, especially his time. >> >> Matej > -- > 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: Using Git and separating translations into their own l10n-LL repository
On Mon, Jan 19, 2009 at 12:57 PM, Matej Urban wrote: > Thanks, Gil, > > I will wait and see, but since I'm a translator/mantainer and since I > doubt I will be able to upload many files at once, the only difference > so far I see, is that I will replace keyboard keystrokes for mouse > clicks. There will be no changelog, which is an improvement :) > > Anyhow, in the end I will use whatever I'll need to do it, but keep > nagging about it. For some reason, I really doubt that single dir for > all po files, is a big programing deal. No obsolete clicks, no hassle, > just pure translation work. For the part where you would want to upload several PO files in one go, it should be feasible to adapt damned-lies (as soon as single PO file uploads are enabled) to upload .tar.gz archives of several PO files. I created a bug report about this at "Allow to also commit archives of PO files (instead of single PO files)" http://bugzilla.gnome.org/show_bug.cgi?id=568295 Simos > > On Mon, Jan 19, 2009 at 1:46 PM, Gil Forcada wrote: >> Hi, >> >> Actually a lot has changed: >> >> - for advanced-translators the same workflow will be maintained. >> - for plain translators a web interface to commit languages will be >> provided. >> >> So I think you fall in the second option and thus you will need to have >> access to http://l10n.gnome.org to download updated po files (like you >> can do right know), track its status (like as of January you can do >> right now) and commit them in source repositories (like you will be able >> to do in a not-so-distant-future, Claude said it has a beta working >> version that does this, I'm right Claude?) >> >> So, all in all, your workflow will be a lot improved since you will only >> have to download and upload files from/to http://l10n.gnome.org :) >> >> Hope I haven't said any lie! >> >> Cheers, >> >> El dl 19 de 01 de 2009 a les 13:38 +0100, en/na Matej Urban va escriure: >>> Hello, >>> >>> I'm really trying to understand the changes. The title sais: >>> Using Git and separating translations into their own l10n-LL repository >>> >>> The title implies that ALL and ONLY po files from ALL the languages UI >>> and HELP will fall into "l10n-LL" repository, but that will not be the >>> case, as I understand. I really don't know why this is so unpopular >>> among developers. >>> >>> I posted a bug http://bugzilla.gnome.org/show_bug.cgi?id=554257 and >>> also a reminder that I don't fill-in the changelog entries. I can not >>> find those great "scripts" in the gnome archive, that will do all the >>> work in my place, nor can I write one, so doing it step by step is the >>> only way I know. It takes TOO much time, TOO much bandwidth and TOO >>> much space to maintain the language. Putting/linking/sync all po files >>> in one single dir solves many problems for coords like myself. >>> >>> Please, guys, check again if there is a way to do that. Last >>> coordinator dropped out of the translation game because this updating >>> took too much of everything, especially his time. >>> >>> Matej >> -- >> 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: Using Git and separating translations into their own l10n-LL repository
Simos, That would be a good news. Matej On Mon, Jan 19, 2009 at 2:26 PM, Simos Xenitellis wrote: > On Mon, Jan 19, 2009 at 12:57 PM, Matej Urban wrote: >> Thanks, Gil, >> >> I will wait and see, but since I'm a translator/mantainer and since I >> doubt I will be able to upload many files at once, the only difference >> so far I see, is that I will replace keyboard keystrokes for mouse >> clicks. There will be no changelog, which is an improvement :) >> >> Anyhow, in the end I will use whatever I'll need to do it, but keep >> nagging about it. For some reason, I really doubt that single dir for >> all po files, is a big programing deal. No obsolete clicks, no hassle, >> just pure translation work. > > For the part where you would want to upload several PO files in one > go, it should be feasible to adapt damned-lies (as soon as single PO > file uploads are enabled) to upload .tar.gz archives of several PO > files. > > I created a bug report about this at > "Allow to also commit archives of PO files (instead of single PO files)" > http://bugzilla.gnome.org/show_bug.cgi?id=568295 > > Simos > >> >> On Mon, Jan 19, 2009 at 1:46 PM, Gil Forcada wrote: >>> Hi, >>> >>> Actually a lot has changed: >>> >>> - for advanced-translators the same workflow will be maintained. >>> - for plain translators a web interface to commit languages will be >>> provided. >>> >>> So I think you fall in the second option and thus you will need to have >>> access to http://l10n.gnome.org to download updated po files (like you >>> can do right know), track its status (like as of January you can do >>> right now) and commit them in source repositories (like you will be able >>> to do in a not-so-distant-future, Claude said it has a beta working >>> version that does this, I'm right Claude?) >>> >>> So, all in all, your workflow will be a lot improved since you will only >>> have to download and upload files from/to http://l10n.gnome.org :) >>> >>> Hope I haven't said any lie! >>> >>> Cheers, >>> >>> El dl 19 de 01 de 2009 a les 13:38 +0100, en/na Matej Urban va escriure: Hello, I'm really trying to understand the changes. The title sais: Using Git and separating translations into their own l10n-LL repository The title implies that ALL and ONLY po files from ALL the languages UI and HELP will fall into "l10n-LL" repository, but that will not be the case, as I understand. I really don't know why this is so unpopular among developers. I posted a bug http://bugzilla.gnome.org/show_bug.cgi?id=554257 and also a reminder that I don't fill-in the changelog entries. I can not find those great "scripts" in the gnome archive, that will do all the work in my place, nor can I write one, so doing it step by step is the only way I know. It takes TOO much time, TOO much bandwidth and TOO much space to maintain the language. Putting/linking/sync all po files in one single dir solves many problems for coords like myself. Please, guys, check again if there is a way to do that. Last coordinator dropped out of the translation game because this updating took too much of everything, especially his time. Matej >>> -- >>> 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: Using Git and separating translations into their own l10n-LL repository
2009/1/19 Matej Urban : > Thanks, Gil, > > I will wait and see, but since I'm a translator/mantainer and since I > doubt I will be able to upload many files at once, the only difference > so far I see, is that I will replace keyboard keystrokes for mouse > clicks. There will be no changelog, which is an improvement :) I don't see how this solution will NOT improve your situation. When you want to commit you just have to upload a file via a web-interface. Which means that you cut both space and bandwitdth down to a minimum, the only thing left is time. You do save the time it takes out to check out the modules and fill out the ChangeLog, but you do not get to save the time you could if you could commit more files at once. But in my opinion that should never be made a possibility (and I'm a translation coordinator not a developer), you use verision control systems (of any kind) to track changes, which makes it easy to revert if you do something wrong, but that hardly makes sense if you commit very large changes. Regards Kenneth PS: I have a commit script I can send you if you want to use it in the meantime, but let me know only if you want to use it as I would have to nicefy it a bit before ot could be used by others. > > Anyhow, in the end I will use whatever I'll need to do it, but keep > nagging about it. For some reason, I really doubt that single dir for > all po files, is a big programing deal. No obsolete clicks, no hassle, > just pure translation work. > > Matej > > On Mon, Jan 19, 2009 at 1:46 PM, Gil Forcada wrote: >> Hi, >> >> Actually a lot has changed: >> >> - for advanced-translators the same workflow will be maintained. >> - for plain translators a web interface to commit languages will be >> provided. >> >> So I think you fall in the second option and thus you will need to have >> access to http://l10n.gnome.org to download updated po files (like you >> can do right know), track its status (like as of January you can do >> right now) and commit them in source repositories (like you will be able >> to do in a not-so-distant-future, Claude said it has a beta working >> version that does this, I'm right Claude?) >> >> So, all in all, your workflow will be a lot improved since you will only >> have to download and upload files from/to http://l10n.gnome.org :) >> >> Hope I haven't said any lie! >> >> Cheers, >> >> El dl 19 de 01 de 2009 a les 13:38 +0100, en/na Matej Urban va escriure: >>> Hello, >>> >>> I'm really trying to understand the changes. The title sais: >>> Using Git and separating translations into their own l10n-LL repository >>> >>> The title implies that ALL and ONLY po files from ALL the languages UI >>> and HELP will fall into "l10n-LL" repository, but that will not be the >>> case, as I understand. I really don't know why this is so unpopular >>> among developers. >>> >>> I posted a bug http://bugzilla.gnome.org/show_bug.cgi?id=554257 and >>> also a reminder that I don't fill-in the changelog entries. I can not >>> find those great "scripts" in the gnome archive, that will do all the >>> work in my place, nor can I write one, so doing it step by step is the >>> only way I know. It takes TOO much time, TOO much bandwidth and TOO >>> much space to maintain the language. Putting/linking/sync all po files >>> in one single dir solves many problems for coords like myself. >>> >>> Please, guys, check again if there is a way to do that. Last >>> coordinator dropped out of the translation game because this updating >>> took too much of everything, especially his time. >>> >>> Matej >> -- >> 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 > ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
Well, I'm sure the devels are able to make the system work in anyway they choose, that's why I yell so loudly to get all the po files of one language into one single directory. Now that would cut down the maintenance. If you take a look the translation process, you see, that it consists of 3 major steps. Acquiring the file(s) to translate, translating and commiting. When you "choose" the file, you have to know what is already translated, what is reserved, proofed ... or under revision. You also have to have a quick access to pot files. How many clicks you need to do that? If it's more than one after visiting the page from your favorite bar, there is something like click/bandwidth/time, that can be improved, right? Translation by itself is an individual project and has nothing to do with the git or svn. How many times did you "correct" a single word, that was not syncd in many translations? Last time I did that I had to "repair" 17 files. Why carry apple by apple from the market if you can take a basket with you. If you need more than one line in svn/git or one click on the website more than it's necessary, there is space for improvement, rignt. Getting the files up and down should mean NO effort. It should be easier then ftp-ing them to some server. The real work, with all the logging and diffing, crediting, upgrading and stuff should start from that point on. The last maintainer quit being a mantainer, because he had no time. The last zip that I sent him for 2.22 some time ago had 83 upgraded files. If someone sends me 83 files to commit, I'd break down and cry ... Then I'd start again yelling about SINGLE FOLDER for one language. Less time needed, less bandwidth, less clicks, less nerves, more translating and proofing. A winning situation. M! On Tue, Jan 20, 2009 at 4:55 PM, Kenneth Nielsen wrote: > 2009/1/19 Matej Urban : >> Thanks, Gil, >> >> I will wait and see, but since I'm a translator/mantainer and since I >> doubt I will be able to upload many files at once, the only difference >> so far I see, is that I will replace keyboard keystrokes for mouse >> clicks. There will be no changelog, which is an improvement :) > > I don't see how this solution will NOT improve your situation. When > you want to commit you just have to upload a file via a web-interface. > Which means that you cut both space and bandwitdth down to a minimum, > the only thing left is time. You do save the time it takes out to > check out the modules and fill out the ChangeLog, but you do not get > to save the time you could if you could commit more files at once. But > in my opinion that should never be made a possibility (and I'm a > translation coordinator not a developer), you use verision control > systems (of any kind) to track changes, which makes it easy to revert > if you do something wrong, but that hardly makes sense if you commit > very large changes. > > Regards Kenneth > > PS: I have a commit script I can send you if you want to use it in the > meantime, but let me know only if you want to use it as I would have > to nicefy it a bit before ot could be used by others. > >> >> Anyhow, in the end I will use whatever I'll need to do it, but keep >> nagging about it. For some reason, I really doubt that single dir for >> all po files, is a big programing deal. No obsolete clicks, no hassle, >> just pure translation work. >> >> Matej >> >> On Mon, Jan 19, 2009 at 1:46 PM, Gil Forcada wrote: >>> Hi, >>> >>> Actually a lot has changed: >>> >>> - for advanced-translators the same workflow will be maintained. >>> - for plain translators a web interface to commit languages will be >>> provided. >>> >>> So I think you fall in the second option and thus you will need to have >>> access to http://l10n.gnome.org to download updated po files (like you >>> can do right know), track its status (like as of January you can do >>> right now) and commit them in source repositories (like you will be able >>> to do in a not-so-distant-future, Claude said it has a beta working >>> version that does this, I'm right Claude?) >>> >>> So, all in all, your workflow will be a lot improved since you will only >>> have to download and upload files from/to http://l10n.gnome.org :) >>> >>> Hope I haven't said any lie! >>> >>> Cheers, >>> >>> El dl 19 de 01 de 2009 a les 13:38 +0100, en/na Matej Urban va escriure: Hello, I'm really trying to understand the changes. The title sais: Using Git and separating translations into their own l10n-LL repository The title implies that ALL and ONLY po files from ALL the languages UI and HELP will fall into "l10n-LL" repository, but that will not be the case, as I understand. I really don't know why this is so unpopular among developers. I posted a bug http://bugzilla.gnome.org/show_bug.cgi?id=554257 and also a reminder that I don't fill-in the changelog entries. I can not find those great "scripts" in the gnome archive, that will do all the >
Re: Using Git and separating translations into their own l10n-LL repository
On Wed, Jan 21, 2009 at 8:27 AM, Matej Urban wrote: > Well, I'm sure the devels are able to make the system work in anyway > they choose, that's why I yell so loudly to get all the po files of > one language into one single directory. Now that would cut down the > maintenance. > > If you take a look the translation process, you see, that it consists > of 3 major steps. Acquiring the file(s) to translate, translating and > commiting. > > When you "choose" the file, you have to know what is already > translated, what is reserved, proofed ... or under revision. You also > have to have a quick access to pot files. How many clicks you need to > do that? If it's more than one after visiting the page from your > favorite bar, there is something like click/bandwidth/time, that can > be improved, right? > > Translation by itself is an individual project and has nothing to do > with the git or svn. > > How many times did you "correct" a single word, that was not syncd in > many translations? Last time I did that I had to "repair" 17 files. > Why carry apple by apple from the market if you can take a basket with > you. If you need more than one line in svn/git or one click on the > website more than it's necessary, there is space for improvement, > rignt. Getting the files up and down should mean NO effort. It should > be easier then ftp-ing them to some server. The real work, with all > the logging and diffing, crediting, upgrading and stuff should start > from that point on. > > The last maintainer quit being a mantainer, because he had no time. > The last zip that I sent him for 2.22 some time ago had 83 upgraded > files. If someone sends me 83 files to commit, I'd break down and cry > ... > > Then I'd start again yelling about SINGLE FOLDER for one language. > Less time needed, less bandwidth, less clicks, less nerves, more > translating and proofing. A winning situation. Hi Matej, Earlier in this thread I mention a possible way to have all translations for each language in its own repository (thus, single folder). There where some advantages and disadvantages with this process. I am not sure if you managed to try it using the test repositories from github.com. I believe there is a potential to adapt the proposal so that the disadvantages are eliminated. If you want to have a look at it, it would be great. I'ld be happy to discuss about it. An alternative to the initial proposal of this thread would be to get damned-lies to allow to commit many translation files, as described in the other thread. The bug report is http://bugzilla.gnome.org/show_bug.cgi?id=568295 Simos > On Tue, Jan 20, 2009 at 4:55 PM, Kenneth Nielsen > wrote: >> 2009/1/19 Matej Urban : >>> Thanks, Gil, >>> >>> I will wait and see, but since I'm a translator/mantainer and since I >>> doubt I will be able to upload many files at once, the only difference >>> so far I see, is that I will replace keyboard keystrokes for mouse >>> clicks. There will be no changelog, which is an improvement :) >> >> I don't see how this solution will NOT improve your situation. When >> you want to commit you just have to upload a file via a web-interface. >> Which means that you cut both space and bandwitdth down to a minimum, >> the only thing left is time. You do save the time it takes out to >> check out the modules and fill out the ChangeLog, but you do not get >> to save the time you could if you could commit more files at once. But >> in my opinion that should never be made a possibility (and I'm a >> translation coordinator not a developer), you use verision control >> systems (of any kind) to track changes, which makes it easy to revert >> if you do something wrong, but that hardly makes sense if you commit >> very large changes. >> >> Regards Kenneth >> >> PS: I have a commit script I can send you if you want to use it in the >> meantime, but let me know only if you want to use it as I would have >> to nicefy it a bit before ot could be used by others. >> >>> >>> Anyhow, in the end I will use whatever I'll need to do it, but keep >>> nagging about it. For some reason, I really doubt that single dir for >>> all po files, is a big programing deal. No obsolete clicks, no hassle, >>> just pure translation work. >>> >>> Matej >>> >>> On Mon, Jan 19, 2009 at 1:46 PM, Gil Forcada wrote: Hi, Actually a lot has changed: - for advanced-translators the same workflow will be maintained. - for plain translators a web interface to commit languages will be provided. So I think you fall in the second option and thus you will need to have access to http://l10n.gnome.org to download updated po files (like you can do right know), track its status (like as of January you can do right now) and commit them in source repositories (like you will be able to do in a not-so-distant-future, Claude said it has a beta working version that does this, I'm right Claude?) So, all in all, your workflow will
Re: Using Git and separating translations into their own l10n-LL repository
On Wed, Jan 21, 2009 at 4:20 AM, Simos Xenitellis wrote: > On Wed, Jan 21, 2009 at 8:27 AM, Matej Urban wrote: >> Well, I'm sure the devels are able to make the system work in anyway >> they choose, that's why I yell so loudly to get all the po files of >> one language into one single directory. Now that would cut down the >> maintenance. > > Earlier in this thread I mention a possible way to have all > translations for each language in its own repository (thus, single > folder). There where some advantages and disadvantages with this > process. I am not sure if you managed to try it using the test > repositories from github.com. > I believe there is a potential to adapt the proposal so that the > disadvantages are eliminated. > If you want to have a look at it, it would be great. I'ld be happy to > discuss about it. Given the number of times that translators have broken the build of our module, Gnome Games, because they don't run make check before they commit. I'm 100% opposed to any configuration in which translators are freed from the responsibility of making sure that they didn't break something. Both of these proposals are good ideas but will cause many headaches unless the make check is automated somehow. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
If damned-lies is able to commit files it will be "trivial" (Claude?) to first check that the dist check is ok. Cheers, El dc 21 de 01 de 2009 a les 10:31 -0600, en/na Jason D. Clinton va escriure: > On Wed, Jan 21, 2009 at 4:20 AM, Simos Xenitellis > wrote: > > On Wed, Jan 21, 2009 at 8:27 AM, Matej Urban wrote: > >> Well, I'm sure the devels are able to make the system work in anyway > >> they choose, that's why I yell so loudly to get all the po files of > >> one language into one single directory. Now that would cut down the > >> maintenance. > > > > Earlier in this thread I mention a possible way to have all > > translations for each language in its own repository (thus, single > > folder). There where some advantages and disadvantages with this > > process. I am not sure if you managed to try it using the test > > repositories from github.com. > > I believe there is a potential to adapt the proposal so that the > > disadvantages are eliminated. > > If you want to have a look at it, it would be great. I'ld be happy to > > discuss about it. > > Given the number of times that translators have broken the build of > our module, Gnome Games, because they don't run make check before they > commit. I'm 100% opposed to any configuration in which translators are > freed from the responsibility of making sure that they didn't break > something. > > Both of these proposals are good ideas but will cause many headaches > unless the make check is automated somehow. > ___ > 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: Using Git and separating translations into their own l10n-LL repository
Le mercredi 21 janvier 2009 à 10:31 -0600, Jason D. Clinton a écrit : > On Wed, Jan 21, 2009 at 4:20 AM, Simos Xenitellis > wrote: > > On Wed, Jan 21, 2009 at 8:27 AM, Matej Urban wrote: > >> Well, I'm sure the devels are able to make the system work in anyway > >> they choose, that's why I yell so loudly to get all the po files of > >> one language into one single directory. Now that would cut down the > >> maintenance. > > > > Earlier in this thread I mention a possible way to have all > > translations for each language in its own repository (thus, single > > folder). There where some advantages and disadvantages with this > > process. I am not sure if you managed to try it using the test > > repositories from github.com. > > I believe there is a potential to adapt the proposal so that the > > disadvantages are eliminated. > > If you want to have a look at it, it would be great. I'ld be happy to > > discuss about it. > > Given the number of times that translators have broken the build of > our module, Gnome Games, because they don't run make check before they > commit. I'm 100% opposed to any configuration in which translators are > freed from the responsibility of making sure that they didn't break > something. > > Both of these proposals are good ideas but will cause many headaches > unless the make check is automated somehow. I suppose you're talking about documentation translation, right? Because for ui translation, I don't see how to break the build when the file pass msgfmt -vc (as required by the SVN hook). For doc translation, yes, damned-lies could be enhanced to build the documentation from the translations and check the result with xmllint. Feel free to add a bug report about this. But this has nothing to do with the location of files in the VCS. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
On Wed, Jan 21, 2009 at 11:31 AM, Claude Paroz wrote: >> Given the number of times that translators have broken the build of >> our module, Gnome Games, because they don't run make check before they >> commit. I'm 100% opposed to any configuration in which translators are >> freed from the responsibility of making sure that they didn't break >> something. >> >> Both of these proposals are good ideas but will cause many headaches >> unless the make check is automated somehow. > > I suppose you're talking about documentation translation, right? Because > for ui translation, I don't see how to break the build when the file > pass msgfmt -vc (as required by the SVN hook). Yep. > For doc translation, yes, damned-lies could be enhanced to build the > documentation from the translations and check the result with xmllint. > Feel free to add a bug report about this. But this has nothing to do > with the location of files in the VCS. I didn't say that it did. It seems like any change that frees translators from the ability to run xmllint and claim they were just following the approved workflow should be considered a regression. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
2009/1/21 Matej Urban : > Well, I'm sure the devels are able to make the system work in anyway > they choose, that's why I yell so loudly to get all the po files of > one language into one single directory. Now that would cut down the > maintenance. It's not just the devel. As I already said, I'm a translation coordinator/commiter and I don't want them in a seperate folder, because I want to be able to easily update the translation against the source code, without having to fumble around with sub modules in git and what have you. > If you take a look the translation process, you see, that it consists > of 3 major steps. Acquiring the file(s) to translate, translating and > commiting. > > When you "choose" the file, you have to know what is already > translated, what is reserved, proofed ... or under revision. You also > have to have a quick access to pot files. Damned lies alrayde have the options download everything from a release set. Look all the way at the bottom of this page: http://l10n.gnome.org/languages/da/gnome-2-26/ui/ > How many clicks you need to > do that? So that would be one > If it's more than one after visiting the page from your > favorite bar, there is something like click/bandwidth/time, that can > be improved, right? > > Translation by itself is an individual project and has nothing to do > with the git or svn. > > How many times did you "correct" a single word, that was not syncd in > many translations? Never, because we have a wordlist which we use pretty consistently > Last time I did that I had to "repair" 17 files. > Why carry apple by apple from the market if you can take a basket with > you. If you need more than one line in svn/git or one click on the > website more than it's necessary, there is space for improvement, > rignt. Getting the files up and down should mean NO effort. Why? It is a task, and as such will require work. In any case, you have already been told that it is certainly possilble to add the option to upload several files at once in Damned Lies, in that case you both have the options to get all files easily and you can have the possibility to commit several files in Damned Lies. The isn't that enough, isn't that exactly what you want, so that we can leave the repositories on their own and in a structure that makes sense i.e. one module-wise. > It should > be easier then ftp-ing them to some server. The real work, with all > the logging and diffing, crediting, upgrading and stuff should start > from that point on. > > The last maintainer quit being a mantainer, because he had no time. > The last zip that I sent him for 2.22 some time ago had 83 upgraded > files. If someone sends me 83 files to commit, I'd break down and cry Yeah, but perhaps you could have sent him something a little before it reached 83 !?! > Then I'd start again yelling about SINGLE FOLDER for one language. > Less time needed, less bandwidth, less clicks, less nerves, more > translating and proofing. A winning situation. > > M! > > On Tue, Jan 20, 2009 at 4:55 PM, Kenneth Nielsen > wrote: >> 2009/1/19 Matej Urban : >>> Thanks, Gil, >>> >>> I will wait and see, but since I'm a translator/mantainer and since I >>> doubt I will be able to upload many files at once, the only difference >>> so far I see, is that I will replace keyboard keystrokes for mouse >>> clicks. There will be no changelog, which is an improvement :) >> >> I don't see how this solution will NOT improve your situation. When >> you want to commit you just have to upload a file via a web-interface. >> Which means that you cut both space and bandwitdth down to a minimum, >> the only thing left is time. You do save the time it takes out to >> check out the modules and fill out the ChangeLog, but you do not get >> to save the time you could if you could commit more files at once. But >> in my opinion that should never be made a possibility (and I'm a >> translation coordinator not a developer), you use verision control >> systems (of any kind) to track changes, which makes it easy to revert >> if you do something wrong, but that hardly makes sense if you commit >> very large changes. >> >> Regards Kenneth >> >> PS: I have a commit script I can send you if you want to use it in the >> meantime, but let me know only if you want to use it as I would have >> to nicefy it a bit before ot could be used by others. >> >>> >>> Anyhow, in the end I will use whatever I'll need to do it, but keep >>> nagging about it. For some reason, I really doubt that single dir for >>> all po files, is a big programing deal. No obsolete clicks, no hassle, >>> just pure translation work. >>> >>> Matej >>> >>> On Mon, Jan 19, 2009 at 1:46 PM, Gil Forcada wrote: Hi, Actually a lot has changed: - for advanced-translators the same workflow will be maintained. - for plain translators a web interface to commit languages will be provided. So I think you fall in the second option and thus you will need t
Re: Using Git and separating translations into their own l10n-LL repository
Hello Simos, I did notice the threads, but was not sure if I really understand what the thread was going about. I am preparing to check it in practice. That was actually the reason, why I am so interested in this thread. I sense real improvement for the work of translators. Thanks, Matej On Wed, Jan 21, 2009 at 11:20 AM, Simos Xenitellis wrote: > On Wed, Jan 21, 2009 at 8:27 AM, Matej Urban wrote: >> Well, I'm sure the devels are able to make the system work in anyway >> they choose, that's why I yell so loudly to get all the po files of >> one language into one single directory. Now that would cut down the >> maintenance. >> >> If you take a look the translation process, you see, that it consists >> of 3 major steps. Acquiring the file(s) to translate, translating and >> commiting. >> >> When you "choose" the file, you have to know what is already >> translated, what is reserved, proofed ... or under revision. You also >> have to have a quick access to pot files. How many clicks you need to >> do that? If it's more than one after visiting the page from your >> favorite bar, there is something like click/bandwidth/time, that can >> be improved, right? >> >> Translation by itself is an individual project and has nothing to do >> with the git or svn. >> >> How many times did you "correct" a single word, that was not syncd in >> many translations? Last time I did that I had to "repair" 17 files. >> Why carry apple by apple from the market if you can take a basket with >> you. If you need more than one line in svn/git or one click on the >> website more than it's necessary, there is space for improvement, >> rignt. Getting the files up and down should mean NO effort. It should >> be easier then ftp-ing them to some server. The real work, with all >> the logging and diffing, crediting, upgrading and stuff should start >> from that point on. >> >> The last maintainer quit being a mantainer, because he had no time. >> The last zip that I sent him for 2.22 some time ago had 83 upgraded >> files. If someone sends me 83 files to commit, I'd break down and cry >> ... >> >> Then I'd start again yelling about SINGLE FOLDER for one language. >> Less time needed, less bandwidth, less clicks, less nerves, more >> translating and proofing. A winning situation. > > Hi Matej, > Earlier in this thread I mention a possible way to have all > translations for each language in its own repository (thus, single > folder). There where some advantages and disadvantages with this > process. I am not sure if you managed to try it using the test > repositories from github.com. > I believe there is a potential to adapt the proposal so that the > disadvantages are eliminated. > If you want to have a look at it, it would be great. I'ld be happy to > discuss about it. > > An alternative to the initial proposal of this thread would be to get > damned-lies to allow to commit many translation files, as described in > the other thread. The bug report is > http://bugzilla.gnome.org/show_bug.cgi?id=568295 > > Simos > >> On Tue, Jan 20, 2009 at 4:55 PM, Kenneth Nielsen >> wrote: >>> 2009/1/19 Matej Urban : Thanks, Gil, I will wait and see, but since I'm a translator/mantainer and since I doubt I will be able to upload many files at once, the only difference so far I see, is that I will replace keyboard keystrokes for mouse clicks. There will be no changelog, which is an improvement :) >>> >>> I don't see how this solution will NOT improve your situation. When >>> you want to commit you just have to upload a file via a web-interface. >>> Which means that you cut both space and bandwitdth down to a minimum, >>> the only thing left is time. You do save the time it takes out to >>> check out the modules and fill out the ChangeLog, but you do not get >>> to save the time you could if you could commit more files at once. But >>> in my opinion that should never be made a possibility (and I'm a >>> translation coordinator not a developer), you use verision control >>> systems (of any kind) to track changes, which makes it easy to revert >>> if you do something wrong, but that hardly makes sense if you commit >>> very large changes. >>> >>> Regards Kenneth >>> >>> PS: I have a commit script I can send you if you want to use it in the >>> meantime, but let me know only if you want to use it as I would have >>> to nicefy it a bit before ot could be used by others. >>> Anyhow, in the end I will use whatever I'll need to do it, but keep nagging about it. For some reason, I really doubt that single dir for all po files, is a big programing deal. No obsolete clicks, no hassle, just pure translation work. Matej On Mon, Jan 19, 2009 at 1:46 PM, Gil Forcada wrote: > Hi, > > Actually a lot has changed: > > - for advanced-translators the same workflow will be maintained. > - for plain translators a web interface to commit languages will be > provided. >
Re: Using Git and separating translations into their own l10n-LL repository
> Damned lies alrayde have the options download everything from a > release set. Look all the way at the bottom of this page: > http://l10n.gnome.org/languages/da/gnome-2-26/ui/ Can I download all the pot files? I'm not aware of it. >> How many times did you "correct" a single word, that was not syncd in >> many translations? > > Never, because we have a wordlist which we use pretty consistently That is something we still have to do. But "pretty consistently" tells me, that it happens, right. > Why? It is a task, and as such will require work. Agreed! But work on translations, not with committing. > In any case, you have already been told that it is certainly possilble to add > the > option to upload several files at once in Damned Lies, in that case > you both have the options to get all files easily and you can have the > possibility to commit several files in Damned Lies. The isn't that > enough, isn't that exactly what you want, so that we can leave the > repositories on their own and in a structure that makes sense i.e. one > module-wise. It would be an improvement, but one folder system would be much better. I believe, that It should not be a big deal keeping the structure intact and syncing the whole lot with single folder. Maybe I'm wrong. > Yeah, but perhaps you could have sent him something a little before it > reached 83 !?! I agree, but at that time I was sure, that he only "ftps" them to repos and thought, I only did him a favour when sending all at once, not giving him too much work ... Funny right :) Matej ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
Hey Matej 2009/1/22 Matej Urban : >> Damned lies alrayde have the options download everything from a >> release set. Look all the way at the bottom of this page: >> http://l10n.gnome.org/languages/da/gnome-2-26/ui/ > > Can I download all the pot files? I'm not aware of it. What do you need pot-files for? You will get updated po-files which is what you need if there already os a translation or a pot-files if there wasn't already one. And yes you can, just press the button that says "Download all po files" at the bottom of the page I just sent you a link for and you will get a tar-ball with all the Danish po/pot-files. I'm sure you can extrapolate that for you own language. > >>> How many times did you "correct" a single word, that was not syncd in >>> many translations? >> >> Never, because we have a wordlist which we use pretty consistently > > That is something we still have to do. But "pretty consistently" tells > me, that it happens, right. > >> Why? It is a task, and as such will require work. > > Agreed! But work on translations, not with committing. That is part of the task. >> In any case, you have already been told that it is certainly possilble to >> add the >> option to upload several files at once in Damned Lies, in that case >> you both have the options to get all files easily and you can have the >> possibility to commit several files in Damned Lies. The isn't that >> enough, isn't that exactly what you want, so that we can leave the >> repositories on their own and in a structure that makes sense i.e. one >> module-wise. > > It would be an improvement, but one folder system would be much > better. Why? If you can commit a tar-ball to Damned Lies with several files in it in one go (one clicky-di-click) and then they will all be commited at once, then isn't that exactly the functionality you are asking for? > I believe, that It should not be a big deal keeping the > structure intact and syncing the whole lot with single folder. Maybe > I'm wrong. >From what I could read from the previous e-mails about how to use git with submodules, to link translations in form their own module, it will be significantly more complex. Regards Kenneth Nielsen >> Yeah, but perhaps you could have sent him something a little before it >> reached 83 !?! > > I agree, but at that time I was sure, that he only "ftps" them to > repos and thought, I only did him a favour when sending all at once, > not giving him too much work ... > Funny right :) > > Matej > ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
On Thu, Jan 22, 2009 at 9:18 AM, Kenneth Nielsen wrote: > Hey Matej > > 2009/1/22 Matej Urban : >>> Damned lies alrayde have the options download everything from a >>> release set. Look all the way at the bottom of this page: >>> http://l10n.gnome.org/languages/da/gnome-2-26/ui/ >> >> Can I download all the pot files? I'm not aware of it. > > What do you need pot-files for? You will get updated po-files which is > what you need if there already os a translation or a pot-files if > there wasn't already one. And yes you can, just press the button that > says "Download all po files" at the bottom of the page I just sent you > a link for and you will get a tar-ball with all the Danish > po/pot-files. I'm sure you can extrapolate that for you own language. > >> How many times did you "correct" a single word, that was not syncd in many translations? >>> >>> Never, because we have a wordlist which we use pretty consistently >> >> That is something we still have to do. But "pretty consistently" tells >> me, that it happens, right. >> >>> Why? It is a task, and as such will require work. >> >> Agreed! But work on translations, not with committing. > > That is part of the task. > >>> In any case, you have already been told that it is certainly possilble to >>> add the >>> option to upload several files at once in Damned Lies, in that case >>> you both have the options to get all files easily and you can have the >>> possibility to commit several files in Damned Lies. The isn't that >>> enough, isn't that exactly what you want, so that we can leave the >>> repositories on their own and in a structure that makes sense i.e. one >>> module-wise. >> >> It would be an improvement, but one folder system would be much >> better. > > Why? If you can commit a tar-ball to Damned Lies with several files in > it in one go (one clicky-di-click) and then they will all be commited > at once, then isn't that exactly the functionality you are asking for? The functionality of being able to submit a single file through the web interface from Damned-lies and make it to GNOME SVN/GIT is not available yet. The ability to submit several files would be an addition to the previous task, and is not available yet either. >> I believe, that It should not be a big deal keeping the >> structure intact and syncing the whole lot with single folder. Maybe >> I'm wrong. > > From what I could read from the previous e-mails about how to use git > with submodules, to link translations in form their own module, it > will be significantly more complex. 'git submodule' is a functionality that was introduced to git quite recently, and the process I described at the start of this thread was indeed complex and most importantly error-prone. So the decision later on in this thread was not to use 'git submodule', in the way described at the start of the thread. Simos > Regards Kenneth Nielsen > >>> Yeah, but perhaps you could have sent him something a little before it >>> reached 83 !?! >> >> I agree, but at that time I was sure, that he only "ftps" them to >> repos and thought, I only did him a favour when sending all at once, >> not giving him too much work ... >> Funny right :) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
>> Why? If you can commit a tar-ball to Damned Lies with several files in >> it in one go (one clicky-di-click) and then they will all be commited >> at once, then isn't that exactly the functionality you are asking for? > > The functionality of being able to submit a single file through the > web interface from Damned-lies and make it to GNOME SVN/GIT is not > available yet. But is planned as something that will come soon as far as I understand. > The ability to submit several files would be an > addition to the previous task, and is not available yet either. Yes, but should then hopefully be a managable task once the other feature is in. >>> I believe, that It should not be a big deal keeping the >>> structure intact and syncing the whole lot with single folder. Maybe >>> I'm wrong. >> >> From what I could read from the previous e-mails about how to use git >> with submodules, to link translations in form their own module, it >> will be significantly more complex. > > 'git submodule' is a functionality that was introduced to git quite recently, > and the process I described at the start of this thread was indeed > complex and most importantly error-prone. So the decision later on in > this thread was not to use 'git submodule', in the way described at > the start of the thread. Ahh ok > > Simos > >> Regards Kenneth Nielsen >> Yeah, but perhaps you could have sent him something a little before it reached 83 !?! >>> >>> I agree, but at that time I was sure, that he only "ftps" them to >>> repos and thought, I only did him a favour when sending all at once, >>> not giving him too much work ... >>> Funny right :) > ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
Hello, It seems that we are maybe a little bit too passionate about it :) > What do you need pot-files for? You will get updated po-files which is > what you need if there already os a translation or a pot-files if > there wasn't already one. There are no pot file in the tar.gz. http://l10n.gnome.org/languages/sl/gnome-2-26/ui.tar.gz This has a lot to do with the way both of us get the job done. I'm sure, that your tech knowledge and awareness keeps you wanting full extra super overview of the situation. I'm looking for simplicity. Since I am coping with something I really do not want to do, I am happy for any improvement. You still seek control. We are exactly on the opposite sites. Basically using single folder or updating directly to DL just my language files in tar.gz, is super OK by me. Single folder can be managed easier, since I can work on my local folder and only sync differences, no need to check which files were changed, no additional copying, no packing, easy word synchronizing and easy management of string database. Upload to DL would be next best thing. >> Agreed! But work on translations, not with committing. > > That is part of the task. I see it as unnecessary part of the task. >> I believe, that It should not be a big deal keeping the >> structure intact and syncing the whole lot with single folder. Maybe >> I'm wrong. > > From what I could read from the previous e-mails about how to use git > with submodules, to link translations in form their own module, it > will be significantly more complex. I don't mind it to be more complex as long as it is not more complex for me. Managing single folder should be as easy as managing any project so far: svn(or whatever) update - updates all the language files if there is more than one committer svn(or whatever) add [filename] - adds files svn(or whatever) delete [filename] - removes them (there might be cases) svn(or whatever) commit 'Some message about the changes' - uploads them The only think to add would be a possibility to "commit as someone eases credit" since all the translators do not have committ rights. If the system is more complex than this, the feature is not implemented to be usable. Matej ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
2009/1/22 Matej Urban : > Hello, > It seems that we are maybe a little bit too passionate about it :) > >> What do you need pot-files for? You will get updated po-files which is >> what you need if there already os a translation or a pot-files if >> there wasn't already one. > > There are no pot file in the tar.gz. > http://l10n.gnome.org/languages/sl/gnome-2-26/ui.tar.gz No as there should not be since there are no untranslated modules. Now I have actually gotten curious, pot files are empty templates, what exactly do you use those for? > This has a lot to do with the way both of us get the job done. I'm > sure, that your tech knowledge and awareness keeps you wanting full > extra super overview of the situation. I'm looking for simplicity. > Since I am coping with something I really do not want to do, I am > happy for any improvement. You still seek control. We are exactly on > the opposite sites. > > Basically using single folder or updating directly to DL just my > language files in tar.gz, is super OK by me. Single folder can be > managed easier, since I can work on my local folder and only sync > differences, no need to check which files were changed, no additional > copying, no packing, easy word synchronizing and easy management of > string database. Upload to DL would be next best thing. > >>> Agreed! But work on translations, not with committing. >> >> That is part of the task. > > I see it as unnecessary part of the task. > >>> I believe, that It should not be a big deal keeping the >>> structure intact and syncing the whole lot with single folder. Maybe >>> I'm wrong. >> >> From what I could read from the previous e-mails about how to use git >> with submodules, to link translations in form their own module, it >> will be significantly more complex. > > I don't mind it to be more complex as long as it is not more complex > for me. No but it will be more complex for me. > Managing single folder should be as easy as managing any > project so far: No because you still need them to find their way back in the modules again to be able to update them against the source code. > svn(or whatever) update - updates all the language files if there is > more than one committer > svn(or whatever) add [filename] - adds files > svn(or whatever) delete [filename] - removes them (there might be cases) > svn(or whatever) commit 'Some message about the changes' - > uploads them > > The only think to add would be a possibility to "commit as someone > eases credit" since all the translators do not have committ > rights. If the system is more complex than this, the feature is not > implemented to be usable. > > Matej > ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
> No as there should not be since there are no untranslated modules. Now > I have actually gotten curious, pot files are empty templates, what > exactly do you use those for? Maybe unconventional, but I update my own po files with latest pots, since I often change translations. Commiting is such a drag, that I take a *.pot, make changes when I have time, wait for new *.pot, translate, wait, again update from *.pot, make more updates, and then when I have some more time, I commit. I am frequently able to translate, but mainly over the weekend to commit. Sound even more rational then I thought. > No but it will be more complex for me. Maybe not, that was not yet determined. Again, there surely is a way to simlink, synch or whatever to satisfy both of us. The http://svn.gnome.org/viewvc/ structure seems to be strict, so why would synching i10n.HEAD-LL - accerciser.HEAD.po - accroc.HEAD.po - alacarte.HEAD.po - alleyoop.HEAD.po - almanah.HEAD.po - anjuta.HEAD.po ... to accerciser/trunk/po/LL.po - accroc/trunk/po/LL.po - alacarte/trunk/po/LL.po - alleyoop/trunk/po/LL.po - almanah/trunk/po/LL.po - anjuta/trunk/po/LL.po ... In the end it will not be me who will do that change. I have no idea how to make it, but you seem more tech-savvy to figure it out. You do the thinking about it, to make us both satisfied, cause I can not be of any help. M! ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
Hi Matej, On Thu, Jan 22, 2009 at 03:00:33PM +0100, Matej Urban wrote: > > No as there should not be since there are no untranslated modules. Now > > I have actually gotten curious, pot files are empty templates, what > > exactly do you use those for? > > Maybe unconventional, but I update my own po files with latest pots, > since I often change translations. Commiting is such a drag, that I > take a *.pot, make changes when I have time, wait for new *.pot, $ svn up $ cd po $ intltool-update LL When finished: $ svn ci Would it be simpler with your approach? One drawback I see with your approach: Are you sure that the pot file is really the latest one? Something in the DL could fail and the pot file won't be updated, so you will use outdated one... > translate, wait, again update from *.pot, make more updates, and then > when I have some more time, I commit. I am frequently able to > translate, but mainly over the weekend to commit. Sound even more > rational then I thought. > > > No but it will be more complex for me. > > Maybe not, that was not yet determined. Again, there surely is a way > to simlink, synch or whatever to satisfy both of us. > The http://svn.gnome.org/viewvc/ structure seems to be strict, so why > would synching > > i10n.HEAD-LL > - accerciser.HEAD.po > - accroc.HEAD.po > - alacarte.HEAD.po > - alleyoop.HEAD.po > - almanah.HEAD.po > - anjuta.HEAD.po > ... > > to > > accerciser/trunk/po/LL.po > - accroc/trunk/po/LL.po > - alacarte/trunk/po/LL.po > - alleyoop/trunk/po/LL.po > - almanah/trunk/po/LL.po > - anjuta/trunk/po/LL.po > ... Nobody is preventing you to make something like this: $ mkdir i10n.HEAD-LL $ cd i10n.HEAD-LL $ ln ../accroc/trunk/po/LL.po accroc.HEAD.po $ ln ../alacarte/trunk/po/LL.po alacarte.HEAD.po (easily scriptable using for, if you want) Update whatever you want in (all, if you want) po files. $ cd .. $ for i in */po ; do cd $i ; svn ci ; done (The scripting above is just an idea, not for real usage) > > In the end it will not be me who will do that change. I have no idea > how to make it, but you seem more tech-savvy to figure it out. You do > the thinking about it, to make us both satisfied, cause I can not be > of any help. Best regards. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | |jabber: mar...@jabber.sk | +---+ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
Hello Marcel, > Nobody is preventing you to make something like this: > > $ mkdir i10n.HEAD-LL > $ cd i10n.HEAD-LL > $ ln ../accroc/trunk/po/LL.po accroc.HEAD.po > $ ln ../alacarte/trunk/po/LL.po alacarte.HEAD.po > (easily scriptable using for, if you want) > > Update whatever you want in (all, if you want) po files. > > $ cd .. > $ for i in */po ; do cd $i ; svn ci ; done > > (The scripting above is just an idea, not for real usage) NOW, here we are again at the start of the problem, already discussed in the bug report I mention. I have no idea how to write a script, that would do what I want, nor did I find any that would closely resemble my wishes. You have to keep in mind, that I couldn't care less about the system and it's specifics, if I could commit all the changed *.po files I keep in my local folder with any tree structure that is used in git/svn system. If I'd have such a script, all other aspects wouldn't bother me. I'd like to go into my gnome.head-LL dir, type $ msusfnt at the beginning and $mscsfnt "somemessage" at the end and all the updates would go into their respected places in the whatever tree structure, back and forth, updating the "somemessage" for all of them, and maybe even, if someone think it's necessary, add suitably formatted entry into the Changelog. Viola. That's it and no more nagging from me. I would gladly give my time to ADD (and other raraly used commands) new files in any, no matter how complicated, way. I can dream, can I? (msusft stands for: Marcel's super updating script for nagging translators) (mscsft stands for: Marcel's super committing script for nagging translators) M! ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
I'm pretty sure that we can come up with a system for at least single file update and commit, in nomatter what VCS we use.Doing it with several is a little more difficult. 2009/1/23 Matej Urban : > Hello Marcel, > >> Nobody is preventing you to make something like this: >> >> $ mkdir i10n.HEAD-LL >> $ cd i10n.HEAD-LL >> $ ln ../accroc/trunk/po/LL.po accroc.HEAD.po >> $ ln ../alacarte/trunk/po/LL.po alacarte.HEAD.po >> (easily scriptable using for, if you want) >> >> Update whatever you want in (all, if you want) po files. >> >> $ cd .. >> $ for i in */po ; do cd $i ; svn ci ; done >> >> (The scripting above is just an idea, not for real usage) > > NOW, here we are again at the start of the problem, already discussed > in the bug report I mention. I have no idea how to write a script, > that would do what I want, nor did I find any that would closely > resemble my wishes. You have to keep in mind, that I couldn't care > less about the system and it's specifics, if I could commit all the > changed *.po files I keep in my local folder with any tree structure > that is used in git/svn system. If I'd have such a script, all other > aspects wouldn't bother me. > > I'd like to go into my gnome.head-LL dir, type $ msusfnt at the > beginning and $mscsfnt "somemessage" at the end and all the updates > would go into their respected places in the whatever tree structure, > back and forth, updating the "somemessage" for all of them, and maybe > even, if someone think it's necessary, add suitably formatted entry > into the Changelog. Viola. That's it and no more nagging from me. > > I would gladly give my time to ADD (and other raraly used commands) > new files in any, no matter how complicated, way. > > I can dream, can I? > > (msusft stands for: Marcel's super updating script for nagging translators) > (mscsft stands for: Marcel's super committing script for nagging translators) > > M! > ___ > 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
