Typos and inconsistencies in source texts

[sveinki]

Hi,

I've been noting down some of the errors my spellcheckers throw at me during translation work on QGIS. (I use several gettext-based applications to beef up productivity, so I do convert the .ts with 'lupdate' back and forth. This allows me to use better spellchecking systems, both on source and translated strings.)

I think most of them should be corrected, and some may need some discussion. I'm only halfway through the source .ts file, and please bear with me the nitpicking

There are several spelling variants of some words. No one of those is "right" - but consistency is more "professional", n'est-ce pas?

• [ ] Quote: "Neighbor is preferred in American English, and neighbour is preferred in all the other main varieties of English. The words are the same in every other respect."
• [x] The same is valid for "flavor/flavour". The source is supposed to be in en_US, right? Or is en_GB more of a convention in GIS?
• [x] We have both "Catalog/Catalogue" and "Favorite/Favourite" - "Favorites/Favourites" in various places.

There are lots of places where we have different verions of the same words:

• [x] For "checkbox" we have also "Check Box" and "check-box".
• [x] We have 8 occurrences of "cell size" and about 20 of "cellsize". BTW; the latter gives an error in various spell-checkers.
• [ ] Similar situation is with "no-data" vs. "nodata", "multi-part/multipart", "single-part/singlepart", "auto-detect/autodetect" "data source/datasource".
• [ ] There's also "Heightbreak/Height break" once each in the QGIS-source; but I see more often "height-break" and "height break" in various documentation on the web.
• [x] There are still some occurences of 'Ctl' instead of 'Ctrl' for the Control-key. For example: "Pin/Unpin Labels And Diagrams\n Click or marquee on label/diagram to pin\n Shift unpins, Ctl (Cmd) toggles state\n Acts on all editable layers"

Spelling errors/doubts:

• [x] "Select a table for editation" --> 'editing' or 'to edit'
• [x] "Cannot convert "%s" to unicode" --> Strictly it should have capitalized 'Unicode'.
• [x] "Mitre limit" --> "Miter limit" is more common US-English I think.
• [ ] "Select the file to analyse" --> There are many occurences of "rasterize", "polygonize" etc. so this should have "analyze". Same should be valid for the string "Colorise" --> "Colorize, "synchronisation/synchronization" and "customisation/customization""
• [x] "Model processed ok." --> For consistency's sake it should be "OK". Same for "If you click Ok, edit mode will automatically be turned on.".
• [x] "Recent algs" --> There really isn't enough space for "Recent algorithms"?
• [x] "Click the icon to bring up the project properties dialog to alter this behaviour." and "Change empty table behaviour" --> "behavior".
• [x] "Error saving layer definintion file" --> "definition".
• [x] "There was an error loading a plugin.The following diagnostic information may help the QGIS developers resolve the issue:\n %1." --> Missing space between 'plugin.' and 'The'.
• [x] "Controls the format used for the geometry column. Defaults to WKB.This is generally more space and processing efficient, but harder to inspect or use in simple applications than WKT (Well Known Text)." --> Missing space between 'WKB.' and 'This'.
• [x] "column_name1[,column_name2, ...] A list of (String) columns that must be compressed with ZLib DEFLATE algorithm. This might be beneficial for databases that have big string blobs. However, use with care, since the value of such columns will be seen as compressed binary content with other SQLite utilities (or previous OGR versions). With OGR, when inserting, modifying or queryings compressed columns, compression/decompression is done transparently. However, such columns cannot be (easily) queried with an attribute filter or WHERE clause. Note: in table definition, such columns have the 'VARCHAR_deflate' declaration type." --> "queryings" has an extra 's' at the end.
• [x] "Enter the name of an action here. The name should be unique (qgis will make it unique if necessary)." --> QGIS should be in capitals, right?
• [x] "If you require a vector-based output file from Qgis it is suggested that you try printing to PostScript if the SVG output is not satisfactory." --> QGIS should be in all-capitals, right?
• [x] "Specifies the underlying units used for scalebar calculations, eg "meters" or "feet" " --> 'eg' should be 'e.g.'. There are also several strings starting with 'Eg,' which should strictly be written 'E.g;' or with an easily understood "For example,".
• [x] "Import cancelled." --> "canceled".

If anyone has the opportunity and patience to grep/submit these corrections into the source code, I'd be grateful.

Best regards, Sveinn í Felli

[nyalldawson]

Is this on master? Favourite should have been fixed as of about a month ago.

Great list by the way!

[nyalldawson]

Just a note that any pr which fixes these should also make corresponding changes to https://github.com/qgis/QGIS/blob/master/scripts/spelling.dat to avoid the bad strings being reintroduced in future.

[sveinki]

Niall, this was taken from the actual .ts file on Transifex two days ago, and then updated this morning.

[sveinki]

Here come my observations for the second half of the file:

• [x] "Granulatiry at which to sample the terrain" --> "Granularity".
• [x] "cancelling" --> "canceling". Both variants may exist, but en_US spellchecking throws an error.
• [x] "Import cancelled." --> "canceled".
• [x] Similar for "labelling" --> "labeling".
• [ ] Occurrences of 'Douglas-Peucker', 'Douglas Peucker' and 'Peucker Douglas' --> We should ask some GIS-nerd about which form is the most used. Interesting problem though; in names of teorems/functions/formulas, is a convention to use alphabetical order or professor-assistant or theory-proof or something arbitrary (which sounds good)?
• [ ] Related is "Fill Sinks|Fill Sinks (Planchon/Darboux, 2001)" --> Should it be "Planchon-Darboux" ?
• [ ] And in "Tasseled Cap (Kauth Thomas) transformation for LANDSAT-ETM 7 raster" --> "Kauth-Thomas" ?
• [x] "Minimise placing labels" --> "Minimize".
• [x] "Capitalise layer names" --> "Capitalize".
• [x] "Uses cartographically 'ideal' placements, prioritising label placement with best visual relationship with the point feature" --> ? "cartographic" ?, "Uses 'ideal' cartographic placements".
  • [x] "Both project CRS (%1) and measured area are in degrees, so area is calculated using cartesian calculations in square degrees." --> "Cartesian" should strictly be capitalized.
• [ ] "Untick save if you don't wish to be the case." --> Weird sentence, probably should be reformulated somehow. First, the use of 'Untick' while other places we use 'Uncheck'. Then 'save' should either be capitalized or be verbing-ed to 'saving. Last, there's probably a missing 'it' after 'wish'. So the string could be something like "Uncheck saving if you don't wish it to be the case.". Still, it's a bit weird, even for a non-native English speaker like me.
• [x] "WARNING: You have entered a password. It will be stored in plain text in your project files and in your home directory on Unix-like systems, or in your user profile on Windows. If you do not want this to happen, please press the Cancel button.\n Note: giving the password is optional. It will be requested interactivly, when needed." --> !"interactivly"! --> "interactively".
• [x] " Row count is determined from table statistics obtained from running the PostgreSQL table analyse function." --> This one is not just cosmetic or stylistic; is the PostgreSQL-function named 'Analyse' or 'Analyze' ?
• [ ] We have both "Upgradable" and "Upgradeable" in various strings; the latter should be correct.
• [x] We have both "doubleclick" and "double-click" in various strings; the latter should be correct.
• [ ] We have both "combobox" and "combo-box" in various strings; the latter should be correct.
• [x] We have both "dropdown" and "drop-down" in various strings; the latter should be correct.
• [ ] One stylistic question; strings like "Import Colors and elevations from xml" and "Export Frequency distribution as csv"; shouldn't it be with capitalized XML and CSV? If it was '.xml' and '.csv' it would be lowercase, but here it really is an acronym, which generally should be in capitals. There are plenty of strings with either lowercase or capitalized versions of similar cases.
• [x] There's "SpatiaLite", "Spatialite" and "spatialite", the last one may sometimes be used as a parameter or inside of a function, thus has a reason to be lowercase. But most of the time it's referring to the name of the database and/or its files. So, "SpatiaLite" should be the norm.
• [x] Similar vein; "Javascript" --> "JavaScript"
• [x] "QGIS is a labour of love by a dedicated team of developers." --> "labor".
• [x] "Export selected symbo(s) as PNG" --> "symbol(s)". BTW; only a few strings use proper plural forms, is there someone working on such phrases? At least my language (Icelandic) has problems with these (form of 'selected' depends on singular/plural, gender and more...).
• [x] "Select a feature (a geometry or an attribut row in the attribute table) and use one of this shortcuts: Ctrl+C to copy, Ctrl+X to cut, and Ctrl+V to paste." --> !"attribut row"! --> "attribute row".
• [x] "Splitted" --> Plain and simple "Split", right ?
• [x] "Error: Unabled to open file [%1]" --> "Unable".

I think I'm now through most of the directly visible strings in the UI. I skipped some strings considering them as professional jargon; "Representativeness", "queryable", "Skeletonization", "Pyramidized" and such. May hurt some delicate souls...

[sveinki]

We can split the observations into categories:

i) Plain typographic errors ii) Stylistic/represenative inconsistencies iii) Language variant non-conformity (en_US vs. en_UK) iv) Grammar errors

and maybe more...

[DelazJ]

Question: What are the folders to check or to avoid when tackling this issue?

• e.g, is the /i18n folder to be checked? Would a replacement of the source text directly in i18n folder avoid translators to redo the translation work (actually the translation is not wrong; it's simply a typo matter in the source - the translator is not faulty)? or would that break things?
• only the whole word or even derivative words (if it's a part of the world)?
• should we fetch only translatable texts? Or comments in the code are concerned? Or even function variables or parameters (as it seems to be done in https://github.com/qgis/QGIS/pull/3888)?

Having some rules or advices from developers here would help people (at least, me) to be less shy on this issue?

Also @nyalldawson when adding terms to the spelling.dat file, if i add flavour: flavor, should I also add flavours:flavors?

[DelazJ]

Is this on master? Favourite should have been fixed as of about a month ago.

Actually, the fix was from a coding perspective. However, we still have:

• some occurrences of the functions containing favourites that were replaced, eg QgsFavouritesItem in /tests/src/python/acceptable_missing_doc.py
• from a translator perspective, many "favourite(s)" occurrences in the Changelog file

As previously asked above, should these files/folders be out of the scope of typos fixes?

[sveinki]

Just seen the #3888; please concentrate on translatable strings, not the API or variable/function names or other programmable items. The problem is about credibility; how an end-user views a product which isn't consistent in it's nomenclature.

[DelazJ]

Sorry @sveinki but I don't agree with you. If only translatable strings matter, actually only English-speaking users would be concerned. When I translate strings, even if there's a typo in the source, I can guess what was meant and translate it the right way into my language so "my" end users are never aware of this error. No harm for QGIS from them.

I'd also prefer to see the big picture. Not only end users are concerned by consistency. Devs also need that, and seeing en-US also in the code may lead to more consistency in that side from the developers, those who introduced the issues (no criticism there, devs). So if it's a matter of search and replace, better do it for all people that deal with QGIS than only a few part.

"Export selected symbo(s) as PNG" --> "symbol(s)". BTW; only a few strings use proper plural forms, is there someone working on such phrases? At least my language (Icelandic) has problems with these (form of 'selected' depends on singular/plural, gender and more...).

In French we also have this problem. (In this case for example, we would need three parentheses which would make Transifex unhappy). I personally do like that (don't care of Transifex complaint) but I've also seen strings with two translated versions (singular and plural forms) in Transifex. But I couldn't find how it was done and actually never really pay attention to the behavior in QGIS application. Maybe a solution is available in Transifex...

[sveinki]

In French we also have this problem. (In this case for example, we would need three parentheses which would make Transifex unhappy). I personally do like that (don't care of Transifex complaint) but I've also seen strings with two translated versions (singular and plural forms) in Transifex.

Well, the mechanism is working in Qt and in Transifex. If you look at the .ts file in a text editor, you can see for example this message in the French file: `

    <source>%n feature(s) deleted.</source>
    <comment>number of features deleted</comment>
    <translation>
        <numerusform>%n entité supprimée</numerusform>
        <numerusform>%n entités supprimées</numerusform>
    </translation>
</message>`

This is how it works for a language with two plurals declared. The problem is that not many of the developers are using this technique.

[DelazJ]

@sveinki I edited your list as task list (to ease the fix). Would be nice to keep checking items that are already fixed or being fixed in a PR

[3nids]

We have a lot of cancellation, which should be switched to cancelation for consistency. Thoughts?

[sveinki]

Well, correcting capitalization is not even finished when someone starts adding new ambiguities; found this in the TS-file:

    <message>
        <location filename="../python/plugins/db_manager/python-i18n.cpp" line="155"/>
        <source>Qgis Geometry type:</source>
        <translation type="unfinished"></translation>
    </message>

QGIS is supposed to be capitalized, right?

Edit: looks like the string is in _QGIS/python/plugins/db_manager/db_plugins/oracle/infomodel.py