Re: [Qgis-developer] [Qgis-tr] size of translations, use a distinct repo?
Hi, 2014-10-31 1:12 GMT+09:00 Werner Macho : > 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? We can download the latest ts file from Transifex and build it with Qt Linguist or lrelease command. So just one time update of translation files in GitHub before every release is enough for me. I use a batch file (below) to build it, and then check the translation appearance with the qgis-dev of OSGeo4W. The message location information must be heavy for the git repository, but it may be useful for translators. I use it to find the relevant source code, for example, to know what string %1 is replaced with (is it replaced with a number? layer name? or error message?). We can see the name of context that a message is located, but it is not always helpful to find the location of message. Without location information, I'll find the source location using "search from files" function of text editor, but it is not efficient way. Is it possible to upload the source ts file with location information to Transifex, and clean up location lines just before the translation files are committed to the git repository? ### build_ts.bat --- call C:\OSGeo4W64\bin\o4w_env.bat SET TS_DIR=translations\QGIS.qgis-application SET TS_LANG=ja SET DEST=C:\OSGeo4W64\apps\qgis-dev\i18n\qgis_%TS_LANG%.qm REM lrelease.exe is included in qt4-devel package of OSGeo4W lrelease %TS_DIR%\%TS_LANG%.ts REM backup original file if not exist %DEST%.orig copy %DEST% %DEST%.orig REM copy the built qm file copy %TS_DIR%\%TS_LANG%.qm %DEST% pause --- Regards, Minoru ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] qgis2threejs issue
Hi Paolo, 2014-10-29 19:12 GMT+09:00 Paolo Cavallini : > Il 28/10/2014 09:36, Minoru Akagi ha scritto: > >> Since the last used control is saved, I did not consider it carefully. >> Now it's ok to change the default controls to OrbitControls, which has >> more functions (e.g. arrow-key control and auto-rotation) and is >> probably suitable for flat earth. > > Hi Minoru, > just tested with OrbitControls, and I still can rotate the plane below the > surface, > which does not seem appropriate to me. It may be possible to add an option to limit rotation in OrbitControls. > BTW, I also have the background canvas shown in white, which also looks bad: > any > solution for this? What browser do you use? I use Chrome, Firefox and IE11 for test. Regards, Minoru ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Error in numpy in QGIS 2.4
Hi, I wanted to invoke a numpy.linspace function and got an error: The error info is in Polish, but the traceback is hopefully readable to the most of you ;) " Wystąpił błąd podczas wykonywania kodu Pythona: Traceback (most recent call last): File "/home/przemek/.qgis2/python/plugins/WarunkiZabudowy/warunkizabudowy.py", line 275, in doSomething lookup_circle = self.circlePolygon(center=point_xy) File "/home/przemek/.qgis2/python/plugins/WarunkiZabudowy/warunkizabudowy.py", line 213, in circlePolygon angles = np.linspace(0, 2*np.pi, nPoints, endpoint=False) File "/usr/lib/python2.7/site-packages/numpy/core/function_base.py", line 82, in linspace num = int(num) AttributeError: WarunkiZabudowy instance has no attribute '__trunc__' Wersja Pythona: 2.7.8 (default, Sep 24 2014, 18:26:21) [GCC 4.9.1 20140903 (prerelease)] Wersja QGIS: 2.4.0-Chugiak Chugiak, ed14cf3 Lokalizacja Pythona: ['/usr/share/qgis/python/plugins/processing', '/home/przemek/.qgis2/python/plugins/GeoCoding', '/usr/share/qgis/python', u'/home/przemek/.qgis2/python', u'/home/przemek/.qgis2/python/plugins', '/usr/share/qgis/python/plugins', '/usr/lib/python2.7/site-packages/ete2-2.2.1072-py2.7.egg', '/home/przemek', '/usr/share/qgis/python', '/usr/lib/python27.zip', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/lib/python2.7/site-packages', '/usr/lib/python2.7/site-packages/gtk-2.0', '/usr/lib/python2.7/site-packages/wx-3.0-gtk2', '/home/przemek/.qgis2/python/plugins/QuickMultiAttributeEdit/forms', '/usr/share/qgis/python/plugins/fTools/tools', '/moje/work/GIAP/decyzje_o_WZ'] " -- Cheers, Przemysław Gierski. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Is it possible to write classification scripts for the graduated renderer in Python?
Hi, Is it possible to write classification scripts for the graduated renderer in Python? I recently had a talk with someone who would like to have an equal area classification and might be willing to add it but I'm not sure if it's possible using Python or if he would have to use C++. Thanks and best wishes, Anita -- anitagraser.com ___ 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?
On 10/30/2014 06:12 PM, 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". a) some translations are very difficult to do if you cannot see "the case" (sometimes developers even invent terms which don't exist in real life!) b) or translators and their friends want to prepare some presentation, teaching, tutorial related material already before the release in their own language ! Cheers, Kari What do you think about that? regards Werner On Thu, Oct 30, 2014 at 4:28 PM, Denis Rouzaud 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 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 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: - + 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 important to have in linguist either. So instead of inventing something new, all it takes might be to add "-locations none" to our lupdate call, reduce the size of the .ts files a lot (in one huge commit) and avoid useless tracking of location changes in the future. Objections? Jürgen -- Kari Salovaara Hanko, Finland "Volunteers do not necessarily have the time; they just have the heart." ~ Elizabeth Andrew ___ 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! 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 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 >> 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 >>> 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: ->>> line="327"/> +>>> 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 >> important to have in linguist either. >> >> So instead of inventing something new, all it takes might be to add >> "-locations none" to our lupdate call, reduce the size of the .ts >> files a lot (in one huge commit) and avoid useless tracking of >> location changes in the future. >> >> Objections? >> >> >> Jürgen >> >> >> >> ___ Qgis-tr mailing list >> qgis...@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/qgis-tr >> > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.15 (GNU/Linux) > > iEYEARECAAYFAlRQ5k8ACgkQDAH1YiCxBgn7TQCeKllHCgzKm1Jn2iRT6iwPXkPd > qmsAnjjWeXZySoZX9WQYf82w4s64s2ql
Re: [Qgis-developer] [Qgis-tr] size of translations, use a distinct repo?
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 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 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: - + 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 important to have in linguist either. So instead of inventing something new, all it takes might be to add "-locations none" to our lupdate call, reduce the size of the .ts files a lot (in one huge commit) and avoid useless tracking of location changes in the future. Objections? Jürgen ___ Qgis-tr mailing list qgis...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-tr -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iEYEARECAAYFAlRQ5k8ACgkQDAH1YiCxBgn7TQCeKllHCgzKm1Jn2iRT6iwPXkPd qmsAnjjWeXZySoZX9WQYf82w4s64s2ql =AGCZ -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-tr mailing list qgis...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-tr ___ Qgis-tr mailing list qgis...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-tr ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QEP/RFC sqlite virtual tables
Hi Martin,
Thanks for your review.
Le 29/10/2014 17:34, Martin Dobias a écrit :
> Hi Hugo!
>
> On Tue, Oct 28, 2014 at 6:15 PM, Hugo Mercier
> wrote:
>> are there other opinions ?
>> Other arguments for one or the other side ?
>
>
> I have to say that initially I was very excited about the idea... and
> after thinking about the details I am getting less excited as there
> are probably lots of gotchas. Below there is list of questions in the
> order of reading the proposal.
>
> ** Use cases
>
> - item 1 - in what sense the layer would be "dynamic"?
"create a dynamic point layer based on X,Y(,Z) coordinates" => if points
coordinates in the underlying layer change, then their geometries can be
updated during the next fetch.
Like for example the creation of a point layer from a CSV file with the
"watch file" option.
>
> ** Indexes
>
> - how will be indexes requested by underlying providers of primary
> sources? Will you add support to providers to return indices
> associated with a given primary source? How can sqlite make use of
> such information? Are you going to replicate the same indices for the
> virtual tables?
Yes we will need something like this in order to properly use indexes of
underlying layers. By populating sqlite_stat* tables.
And yes I realize that may involve replication of indexes.
For the case where more than one index is available on a table, the
xBestIndex method of the virtual table mechanism is made for that: an
estimated cost can be returned for each constraint
>
> - the need to use spatial indices explicitly (with such weird syntax)
> is not good - this should be done by DBMS, not by the user. In
> practice nobody will use them and the spatial queries will be slow
Yes it is the Spatialite spatial index syntax.
>
> ** Serialization
>
> - I am lost. Are we going to materialize those sqlite views in memory
> or to disk? I thought they were meant to be just views wrapping QGIS
> layers
Yes, they are. They can be part of a project file. The second paragraph
is misleading.
>
> ** Implementation details
>
> - regarding QgsVectorLayer constructor: to me it does not look like a
> case special enough to require a new parameter
>
> - what does it mean the provider would be based on spatialite? a
> subclass of spatialite provider - or a copy of it - or something else?
Not decided yet. But it is probably too early in the discussion to go
into such details.
>
> - are the insert/update/delete triggers going to be provided by user
> or generated automatically? (I believe it should be automatic)
As automatic as possible. But in the general case, it is not possible.
Some columns cannot be updated (computed during the query). Or there may
be more than one possibility to "update" a join.
>
> - how do we find out that the views from virtual layers are actually editable?
If an update trigger is defined.
>
> - how do we determine whether the view has a geometry - and in case of
> multiple geometries, which one to choose? (geometry columns are just
> ordinary blobs, right?)
>
> - how do we determine primary key for a view? (for feature IDs)
Good points. We will need to pass these information to the constructor,
as it is now with a postgres provider
>
> ** Python bindings
>
> - how would I create a virtual layer from Python? I would hope to do
> something like iface.addVectorLayer("SELECT * FROM layerX", "virtual")
> - would that be possible?
This kind of syntax (using loaded layer names instead of their explicit
definition) is clean but would require :
* that layers are already loaded before we can use them
* then to save the "loading order" of layers in the project file
The document refers to the use of explicit layer urls.
I don't have a strong opinion on this choice.
>
> ** User interface
>
> - what is the "referenced layers" box for - is it just to inform user
> which layers he used? Or does he need to explicitly register those
> "primary" layers somewhere?
See previous answer
>
> ** Performance
>
> - how will sqlite plan execution of queries?
> - inner join of two virtual tables based on attributes?
> - spatial joins?
> - does sqlite have access to any statistics of virtual tables and
> indices? These are quite important for reasonable query execution
> plans.
See answer more on the top: sqlite_stat* tables, xBestIndex
>
> - During normal operation when iterating over vector layer there is
> conversion: backend -> QgsFeature. As far as I understand the virtual
> tables add two more conversions during execution: QgsFeature -> sqlite
> -> QgsFeature (first in virtual table implementation, second in new
> provider implementation). Is that correct? Have you tried to measure
> additional overhead?
Hmmm correct. I did not have any measure yet ...
>
>
> In summary:
>
> I have the impression that virtual tables are just a simple way to
> provide access to external data to sqlite, not an invitation to use
> sqlite engine with "foreign" data. The provi
[Qgis-developer] Attribute table in Master - 2 issues
1) Updating of values using Field calculator Using master, I select some rows in an attribute table (the data is in PostGIS). I use field calculator to update the values of an existing column in my selected rows. These new values will not display until I close the attribute table and open it again. 2) Row selection (blue highlight) If I click and drag down or up while the mouse button is still held down, I can select multiple rows. These rows are highlighted in blue. If I do this a 2nd time, when I first click the mouse button, the old selection is still shown in the blue highlight. The old selection highlight only disappears when I am finished with my new selection and release the mouse button. This for me isn't the correct behavior that I would expect. However, if you select a set of rows, and then make another program the focused window, if then click back into the attribute table and drag a selection (the action of click and drag has to be the thing that gives the attribute table focus back), it displays the correct behavior I would expect (i.e. the previous selection highlight is removed straight after I have clicked with the mouse button). If I return focus to the attribute table window first and then click and drag, it still displays the wrong behavior. Is anyone else experiencing these problems? I am using Windows 7. Apologies if these have already been reported. Regards, James ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
