[Qgis-developer] 2.6: first overview
Hi all, just few things I'm experiencing with 2.6: Attribute Table: modifying the content of a cell, it needs to save and reopen the table to see it updated...normal behaviour? Crash: different types. Usually closing the project, QGIS ends up with a minidump or the MS error window The software stopped to work etc etc. This happens closing .qgs from 2.2 with or without saving to 2.6 version. Sometimes also while working. Attached you can find the .dmp (shall I upload them? I don't know how to deal with). Actually it's a quite annoying issue... Corrupt layers: the table appears but double-clicking the source it doesn't open the explorer as in 2.2; it only allows to modify the folder destination as text. Is that the new behavior? Translation (ITA): just few oversights: color selection panel: incolla collore modify widget properties: il widget di modica può... Is there anyone with the same issues? I'm working with W8.1 64bit and QGIS standalone. As always: thank you all for your work! All the best, Nic ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 2.6: first overview
Hi! Regarding translation it is now easier than ever before to contribute and change the things yourself. Just get an account on transifex [0] and apply for the italian language - search for the typos and change them by yourself. That way you make sure the correct string will find it's way into the next release. kind regards Werner [0] https://www.transifex.com/projects/p/QGIS On Sun, Nov 2, 2014 at 11:11 PM, Niccolò Marchi sciurusurba...@hotmail.it wrote: Hi all, just few things I'm experiencing with 2.6: Attribute Table: modifying the content of a cell, it needs to save and reopen the table to see it updated...normal behaviour? Crash: different types. Usually closing the project, QGIS ends up with a minidump or the MS error window The software stopped to work etc etc. This happens closing .qgs from 2.2 with or without saving to 2.6 version. Sometimes also while working. Attached you can find the .dmp (shall I upload them? I don't know how to deal with). Actually it's a quite annoying issue... Corrupt layers: the table appears but double-clicking the source it doesn't open the explorer as in 2.2; it only allows to modify the folder destination as text. Is that the new behavior? Translation (ITA): just few oversights: color selection panel: incolla collore modify widget properties: il widget di modica può... Is there anyone with the same issues? I'm working with W8.1 64bit and QGIS standalone. As always: thank you all for your work! All the best, Nic ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re : 2.6: first overview
Hi, About corrupted layers, yes this is the new behaviour. You can now directly write the good path. But there is also a browser button at the bottom of the dialog. Select the layer in the list and click on this button will open the explorer, as old double-click behaved. Envoyé depuis mon HTC - Reply message - De : Werner Macho werner.ma...@gmail.com Pour : Niccolò Marchi sciurusurba...@hotmail.it Cc : qgis-developer@lists.osgeo.org qgis-developer@lists.osgeo.org Objet : [Qgis-developer] 2.6: first overview Date : dim., nov. 2, 2014 23:29 Hi! Regarding translation it is now easier than ever before to contribute and change the things yourself. Just get an account on transifex [0] and apply for the italian language - search for the typos and change them by yourself. That way you make sure the correct string will find it's way into the next release. kind regards Werner [0] https://www.transifex.com/projects/p/QGIS On Sun, Nov 2, 2014 at 11:11 PM, Niccolò Marchi sciurusurba...@hotmail.it wrote: Hi all, just few things I'm experiencing with 2.6: Attribute Table: modifying the content of a cell, it needs to save and reopen the table to see it updated...normal behaviour? Crash: different types. Usually closing the project, QGIS ends up with a minidump or the MS error window The software stopped to work etc etc. This happens closing .qgs from 2.2 with or without saving to 2.6 version. Sometimes also while working. Attached you can find the .dmp (shall I upload them? I don't know how to deal with). Actually it's a quite annoying issue... Corrupt layers: the table appears but double-clicking the source it doesn't open the explorer as in 2.2; it only allows to modify the folder destination as text. Is that the new behavior? Translation (ITA): just few oversights: color selection panel: incolla collore modify widget properties: il widget di modica può... Is there anyone with the same issues? I'm working with W8.1 64bit and QGIS standalone. As always: thank you all for your work! All the best, Nic ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 2.6: first overview
Niccola, With regards to point 1 2, you would increase the chance of those issues being fixed (and help QGIS) by filing tickets at hub.qgis.org . Be as descriptive as you can, provide steps to reproduce what affects you; that should be enough to get a developer to look into it. Sample data source project file leading to issue a bonus. M On 3 Nov 2014 05:16, Niccolò Marchi sciurusurba...@hotmail.it wrote: Hi all, just few things I'm experiencing with 2.6: - *Attribute Table*: modifying the content of a cell, it needs to save and reopen the table to see it updated...normal behaviour? - *Crash*: different types. Usually closing the project, QGIS ends up with a minidump or the MS error window The software stopped to work etc etc. This happens closing .qgs from 2.2 with or without saving to 2.6 version. Sometimes also while working. Attached you can find the .dmp (shall I upload them? I don't know how to deal with). Actually it's a quite annoying issue... - *Corrupt layers*: the table appears but double-clicking the source it doesn't open the explorer as in 2.2; it only allows to modify the folder destination as text. Is that the new behavior? - *Translation **(**ITA**)*: just few oversights: - color selection panel: incolla co*ll*ore - modify widget properties: il widget di *modica* può... Is there anyone with the same issues? I'm working with W8.1 64bit and QGIS standalone. As always: thank you all for your work! All the best, Nic ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 2.6: first overview
Nic, I upgraded to 2.6.0 x64 using the stand-alone installer for Windows (I have two machines: OS 8 and 7 SP1). I am not experiencing the attribute table editing issue that you describe. I experienced a couple of crash dump error windows on exit, but these were mostly while saving older QGIS documents to the new format that also had pathing problems to some layers. Once saved as a 2.6 doc, I have not had any crash dump errors on exit. Also, with respect to the Browse option for unhandled layers, it was greyed out for me when the referenced MSSQL spatial DB had already been deleted. Obviously, these layers were inconsequential, but it would have been easy to manually enter the new instance path had I needed to. Love the new features and improvements with 2.6... All the best, James From: sciurusurba...@hotmail.it To: qgis-developer@lists.osgeo.org Date: Sun, 2 Nov 2014 23:11:14 +0100 Subject: [Qgis-developer] 2.6: first overview Hi all, just few things I'm experiencing with 2.6: Attribute Table: modifying the content of a cell, it needs to save and reopen the table to see it updated...normal behaviour? Crash: different types. Usually c losing the project, QGIS ends up with a minidump or the MS error window The software stopped to work etc etc. This happens closing .qgs from 2.2 with or without saving to 2.6 version. Sometimes also while working. Attached you can find the .dmp (shall I upload them? I don't know how to deal with). Actually it's a quite annoying issue... Corrupt layers: the table appears but double-clicking the source it doesn't open the explorer as in 2.2; it only allows to modify the folder destination as text. Is that the new behavior? Translation (ITA): just few oversights: color selection panel: incolla collore modify widget properties: il widget di modica può... Is there anyone with the same issues? I'm working with W8.1 64bit and QGIS standalone. As always: thank you all for your work! All the best, Nic ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-tr] size of translations, use a distinct repo?
Hi again, Thanks again for you work Werner. Last translation commit is quite large again, due to the Spanish file, although from a quick look it just seems to be new translations... Anyway, I'd like to raise again the idea of using git submodule for translation files. As written before, I think they are quite useless in the main repo. Even if we can limit drastically the growth of the files, I think they would be better suited in a distinct repo and have a small advantage regarding growth of the main repo. I found a project [0] which is using github / transifex with git submodule for translation files [1]. I believe no changes to current translation scripts would be required thanks to git submodules. It would just be a question of initialising the submodule and changing the url wherever needed. Does this need a QEP ? ;) Best wishes, Denis [0] http://www.ushahidi.com/2012/08/21/localization-and-translation-with-transifex/ [1] https://github.com/ushahidi/Ushahidi_Web/tree/develop/application On 30.10.2014 17:12, Werner Macho wrote: Hi! I am sorry for not realizing that :( But from now on it should be much better .. Other thing is that I think about only updating all translations in source only every two weeks (or probably only in front of a release) as the translation should be done in transifex anyway. And only updating the english source in transifex (and master of course). Pros: even smaller and less commits, Cons: Some translators often like to see how it looks like and I understand that from time to time you want to see if it fits. What do you think about that? regards Werner On Thu, Oct 30, 2014 at 4:28 PM, Denis Rouzaud denis.rouz...@gmail.com wrote: Hi Werner, Thanks for this, indeed last translation commit is indeed much smaller Less than 1k lines while it used to be about 50k before. Cheers, Denis On 29.10.2014 20:49, Werner Macho wrote: Hi! I added the suggestion from jef and tried the new produced ts files in linguist and transifex without any problems .. So I decided to update everything again (with strings and transifex update) .. ts files should now have no location inside any more .. I hope that shrinks down the size from now on. regards Werner On Wed, Oct 29, 2014 at 2:56 PM, Stott, James fmro...@fylkesmannen.no wrote: As a slight side point, according to transifex it looks like we could have 13 fully translated languages for the GUI by the time 2.6 is released (13 languages are on 99% or more). 15 languages are over 95%. This is excellent news. Is it something we should publise, maybe add to the visual changelog? -Opprinnelig melding- Fra: qgis-tr-boun...@lists.osgeo.org [mailto:qgis-tr-boun...@lists.osgeo.org] På vegne av Werner Macho Sendt: 29. oktober 2014 14:15 Til: Denis Rouzaud Kopi: QGIS Translation Discussions; qgis-developer Emne: Re: [Qgis-tr] [Qgis-developer] size of translations, use a distinct repo? hmm - ok .. Then I am going to give it a try without location and see if there are any problems with transifex or linguist .. If not - I also think that way is perfect .. regards Werner On Wed, Oct 29, 2014 at 2:11 PM, Denis Rouzaud denis.rouz...@gmail.com wrote: On 29.10.2014 14:06, Werner Macho wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Good idea, if its really translation that causes the growth we should do everything to avoid that. As Jurgen noticed, there are some useless changes in the ts files: message -location filename=../src/core/qgscontexthelp_texts.cpp line=327/ +location filename=../src/core/qgscontexthelp_texts.cpp line=319/ if there are lines removed/added in the source file, this will cause changes in the translation file. Jurgen suggested to remove these tags location filename which would improve a lot. Is there any way to shrink the already existing repo? At one point I thought about zipping the ts files - but if there is a better way .. good! I always wondered why the whole translations file has to be changed whenever there are only some small changes .. moving the translation in it's own github repository: hmm - I don't know if thats easily possible.. but I am also willing to try it if it helps the source code to stay clean. I don't see any reason why it wouldn't be possible. git submodules would be pretty useful for this matter. But again - anyway to shrink the already existing source code? As far as I know, you can't shrink existing repo without destroying the history. I don't mind about loosing track of translation changes. regards Werner On 10/29/2014 12:15 PM, Jürgen E. Fischer wrote: Hi Denis, On Wed, 29. Oct 2014 at 11:08:16 +0100, Denis Rouzaud wrote: Any thoughts? I guess this is just due to the location filename stuff. That often causes massive change in the ts files, because lines were added or removed from the source files - even if there isn't even a changed translation. I think that is not used at all for transifex and it's not that
Re: [Qgis-developer] [Qgis-tr] size of translations, use a distinct repo?
On 03/11/2014 6:32 pm, Denis Rouzaud denis.rouz...@gmail.com wrote: Hi again, Thanks again for you work Werner. Last translation commit is quite large again, due to the Spanish file, although from a quick look it just seems to be new translations... Anyway, I'd like to raise again the idea of using git submodule for translation files. Would this also help us fine tune commit permissions on both repos? I'd imagine that there's a lot of non developers who could potentially benefit from commit rights for translations? As written before, I think they are quite useless in the main repo. Even if we can limit drastically the growth of the files, I think they would be better suited in a distinct repo and have a small advantage regarding growth of the main repo. +1 Nyall I found a project [0] which is using github / transifex with git submodule for translation files [1]. I believe no changes to current translation scripts would be required thanks to git submodules. It would just be a question of initialising the submodule and changing the url wherever needed. Does this need a QEP ? ;) Best wishes, Denis [0] http://www.ushahidi.com/2012/08/21/localization-and-translation-with-transifex/ [1] https://github.com/ushahidi/Ushahidi_Web/tree/develop/application On 30.10.2014 17:12, Werner Macho wrote: Hi! I am sorry for not realizing that :( But from now on it should be much better .. Other thing is that I think about only updating all translations in source only every two weeks (or probably only in front of a release) as the translation should be done in transifex anyway. And only updating the english source in transifex (and master of course). Pros: even smaller and less commits, Cons: Some translators often like to see how it looks like and I understand that from time to time you want to see if it fits. What do you think about that? regards Werner On Thu, Oct 30, 2014 at 4:28 PM, Denis Rouzaud denis.rouz...@gmail.com wrote: Hi Werner, Thanks for this, indeed last translation commit is indeed much smaller Less than 1k lines while it used to be about 50k before. Cheers, Denis On 29.10.2014 20:49, Werner Macho wrote: Hi! I added the suggestion from jef and tried the new produced ts files in linguist and transifex without any problems .. So I decided to update everything again (with strings and transifex update) .. ts files should now have no location inside any more .. I hope that shrinks down the size from now on. regards Werner On Wed, Oct 29, 2014 at 2:56 PM, Stott, James fmro...@fylkesmannen.no wrote: As a slight side point, according to transifex it looks like we could have 13 fully translated languages for the GUI by the time 2.6 is released (13 languages are on 99% or more). 15 languages are over 95%. This is excellent news. Is it something we should publise, maybe add to the visual changelog? -Opprinnelig melding- Fra: qgis-tr-boun...@lists.osgeo.org [mailto:qgis-tr-boun...@lists.osgeo.org] På vegne av Werner Macho Sendt: 29. oktober 2014 14:15 Til: Denis Rouzaud Kopi: QGIS Translation Discussions; qgis-developer Emne: Re: [Qgis-tr] [Qgis-developer] size of translations, use a distinct repo? hmm - ok .. Then I am going to give it a try without location and see if there are any problems with transifex or linguist .. If not - I also think that way is perfect .. regards Werner On Wed, Oct 29, 2014 at 2:11 PM, Denis Rouzaud denis.rouz...@gmail.com wrote: On 29.10.2014 14:06, Werner Macho wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Good idea, if its really translation that causes the growth we should do everything to avoid that. As Jurgen noticed, there are some useless changes in the ts files: message -location filename=../src/core/qgscontexthelp_texts.cpp line=327/ +location filename=../src/core/qgscontexthelp_texts.cpp line=319/ if there are lines removed/added in the source file, this will cause changes in the translation file. Jurgen suggested to remove these tags location filename which would improve a lot. Is there any way to shrink the already existing repo? At one point I thought about zipping the ts files - but if there is a better way .. good! I always wondered why the whole translations file has to be changed whenever there are only some small changes .. moving the translation in it's own github repository: hmm - I don't know if thats easily possible.. but I am also willing to try it if it helps the source code to stay clean. I don't see any reason why it wouldn't be possible. git submodules would be pretty useful for this matter. But again - anyway to shrink the already existing source code? As far as I know, you can't shrink existing repo without destroying the history. I don't mind about loosing track of translation changes. regards Werner On 10/29/2014 12:15 PM, Jürgen E. Fischer wrote: Hi Denis, On Wed,
Re: [Qgis-developer] [Qgis-tr] size of translations, use a distinct repo?
Hi Denis! Yeah - unfortunately I missed spanish from transifex (sorry to carlos for that). But that should now be a normal commit for a language update. As I said already.. I tend to only update english source from master to transifex and only frequently port translations back like once in a month and before releases every 3 days or so for 2 weeks. We should give translators the chance to see in testing how the translation looks like. Using a git submodule would also be good to me .. that would probably make the above more easier .. Personally I never used submodules and I don't want to break anything .. So if anyone with experience can do it .. step ahead .. If noone will do it I will try to implement it myself (hopefully without breaking anything). I don't know if this a QEP case as it is nothing technical with GIS itself but rather administrative .. Ask the PSC? kind regards Werner On Mon, Nov 3, 2014 at 8:32 AM, Denis Rouzaud denis.rouz...@gmail.com wrote: Hi again, Thanks again for you work Werner. Last translation commit is quite large again, due to the Spanish file, although from a quick look it just seems to be new translations... Anyway, I'd like to raise again the idea of using git submodule for translation files. As written before, I think they are quite useless in the main repo. Even if we can limit drastically the growth of the files, I think they would be better suited in a distinct repo and have a small advantage regarding growth of the main repo. I found a project [0] which is using github / transifex with git submodule for translation files [1]. I believe no changes to current translation scripts would be required thanks to git submodules. It would just be a question of initialising the submodule and changing the url wherever needed. Does this need a QEP ? ;) Best wishes, Denis [0] http://www.ushahidi.com/2012/08/21/localization-and-translation-with-transifex/ [1] https://github.com/ushahidi/Ushahidi_Web/tree/develop/application On 30.10.2014 17:12, Werner Macho wrote: Hi! I am sorry for not realizing that :( But from now on it should be much better .. Other thing is that I think about only updating all translations in source only every two weeks (or probably only in front of a release) as the translation should be done in transifex anyway. And only updating the english source in transifex (and master of course). Pros: even smaller and less commits, Cons: Some translators often like to see how it looks like and I understand that from time to time you want to see if it fits. What do you think about that? regards Werner On Thu, Oct 30, 2014 at 4:28 PM, Denis Rouzaud denis.rouz...@gmail.com wrote: Hi Werner, Thanks for this, indeed last translation commit is indeed much smaller Less than 1k lines while it used to be about 50k before. Cheers, Denis On 29.10.2014 20:49, Werner Macho wrote: Hi! I added the suggestion from jef and tried the new produced ts files in linguist and transifex without any problems .. So I decided to update everything again (with strings and transifex update) .. ts files should now have no location inside any more .. I hope that shrinks down the size from now on. regards Werner On Wed, Oct 29, 2014 at 2:56 PM, Stott, James fmro...@fylkesmannen.no wrote: As a slight side point, according to transifex it looks like we could have 13 fully translated languages for the GUI by the time 2.6 is released (13 languages are on 99% or more). 15 languages are over 95%. This is excellent news. Is it something we should publise, maybe add to the visual changelog? -Opprinnelig melding- Fra: qgis-tr-boun...@lists.osgeo.org [mailto:qgis-tr-boun...@lists.osgeo.org] På vegne av Werner Macho Sendt: 29. oktober 2014 14:15 Til: Denis Rouzaud Kopi: QGIS Translation Discussions; qgis-developer Emne: Re: [Qgis-tr] [Qgis-developer] size of translations, use a distinct repo? hmm - ok .. Then I am going to give it a try without location and see if there are any problems with transifex or linguist .. If not - I also think that way is perfect .. regards Werner On Wed, Oct 29, 2014 at 2:11 PM, Denis Rouzaud denis.rouz...@gmail.com wrote: On 29.10.2014 14:06, Werner Macho wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Good idea, if its really translation that causes the growth we should do everything to avoid that. As Jurgen noticed, there are some useless changes in the ts files: message -location filename=../src/core/qgscontexthelp_texts.cpp line=327/ +location filename=../src/core/qgscontexthelp_texts.cpp line=319/ if there are lines removed/added in the source file, this will cause changes in the translation file. Jurgen suggested to remove these tags location filename which would improve a lot. Is there any way to shrink the already existing repo? At one point I thought about zipping the ts files - but if there
Re: [Qgis-developer] [Qgis-tr] size of translations, use a distinct repo?
Hi Nyall! Commit rights for translations are solved by using transifex (which is a better, webbased, intuitive was for doing translations anyway) If you insist on using linguist you can even download and upload the *.ts files directly in transifex. No need to deal with git. kind regards Werner On Mon, Nov 3, 2014 at 8:36 AM, Nyall Dawson nyall.daw...@gmail.com wrote: On 03/11/2014 6:32 pm, Denis Rouzaud denis.rouz...@gmail.com wrote: Hi again, Thanks again for you work Werner. Last translation commit is quite large again, due to the Spanish file, although from a quick look it just seems to be new translations... Anyway, I'd like to raise again the idea of using git submodule for translation files. Would this also help us fine tune commit permissions on both repos? I'd imagine that there's a lot of non developers who could potentially benefit from commit rights for translations? As written before, I think they are quite useless in the main repo. Even if we can limit drastically the growth of the files, I think they would be better suited in a distinct repo and have a small advantage regarding growth of the main repo. +1 Nyall I found a project [0] which is using github / transifex with git submodule for translation files [1]. I believe no changes to current translation scripts would be required thanks to git submodules. It would just be a question of initialising the submodule and changing the url wherever needed. Does this need a QEP ? ;) Best wishes, Denis [0] http://www.ushahidi.com/2012/08/21/localization-and-translation-with-transifex/ [1] https://github.com/ushahidi/Ushahidi_Web/tree/develop/application On 30.10.2014 17:12, Werner Macho wrote: Hi! I am sorry for not realizing that :( But from now on it should be much better .. Other thing is that I think about only updating all translations in source only every two weeks (or probably only in front of a release) as the translation should be done in transifex anyway. And only updating the english source in transifex (and master of course). Pros: even smaller and less commits, Cons: Some translators often like to see how it looks like and I understand that from time to time you want to see if it fits. What do you think about that? regards Werner On Thu, Oct 30, 2014 at 4:28 PM, Denis Rouzaud denis.rouz...@gmail.com wrote: Hi Werner, Thanks for this, indeed last translation commit is indeed much smaller Less than 1k lines while it used to be about 50k before. Cheers, Denis On 29.10.2014 20:49, Werner Macho wrote: Hi! I added the suggestion from jef and tried the new produced ts files in linguist and transifex without any problems .. So I decided to update everything again (with strings and transifex update) .. ts files should now have no location inside any more .. I hope that shrinks down the size from now on. regards Werner On Wed, Oct 29, 2014 at 2:56 PM, Stott, James fmro...@fylkesmannen.no wrote: As a slight side point, according to transifex it looks like we could have 13 fully translated languages for the GUI by the time 2.6 is released (13 languages are on 99% or more). 15 languages are over 95%. This is excellent news. Is it something we should publise, maybe add to the visual changelog? -Opprinnelig melding- Fra: qgis-tr-boun...@lists.osgeo.org [mailto:qgis-tr-boun...@lists.osgeo.org] På vegne av Werner Macho Sendt: 29. oktober 2014 14:15 Til: Denis Rouzaud Kopi: QGIS Translation Discussions; qgis-developer Emne: Re: [Qgis-tr] [Qgis-developer] size of translations, use a distinct repo? hmm - ok .. Then I am going to give it a try without location and see if there are any problems with transifex or linguist .. If not - I also think that way is perfect .. regards Werner On Wed, Oct 29, 2014 at 2:11 PM, Denis Rouzaud denis.rouz...@gmail.com wrote: On 29.10.2014 14:06, Werner Macho wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Good idea, if its really translation that causes the growth we should do everything to avoid that. As Jurgen noticed, there are some useless changes in the ts files: message -location filename=../src/core/qgscontexthelp_texts.cpp line=327/ +location filename=../src/core/qgscontexthelp_texts.cpp line=319/ if there are lines removed/added in the source file, this will cause changes in the translation file. Jurgen suggested to remove these tags location filename which would improve a lot. Is there any way to shrink the already existing repo? At one point I thought about zipping the ts files - but if there is a better way .. good! I always wondered why the whole translations file has to be changed whenever there are only some small changes .. moving the translation in it's own github repository: hmm - I don't know if thats easily possible.. but I am also willing to try it if it helps the source code to stay clean. I don't see
