Closed hartenthaler closed 1 year ago
There are several non-balanced HTML tags in the translation code visible (like opening and not ending or ending but not opening
). In general I would prefer not to see them at all (then you have to cut the translation string into pieces) or to see both of them (then you have to move the missing HTML tags into the string).
Initially, the help text was something like "Select the individuals to grow the tree from". This was an independent string of text and the code was something like <p><?= translate("Select the individuals to grow the tree from"); ?></p>
(abbreviated).
Then I started adding longer and longer explanations, and so I needed to close the <p>
tag for some of them before starting a new section, and today, most of them are like this. I agree it's not ideal, I should update them all to move the starting/ending <p>
tag into the translation term.
I would prefer this instead of cutting the text into small pieces. I feel translating may be difficult if you don't have the text together to see the context.
Especially there is a problem in the translated help text (i) for "Treatment of source individual":
* in German there is an additional `<p>` visible * in Catalan there is a wrong `< h4>`
Both of these issues seem to be due to an extra space in the tag (e.g. in German it's < p>
instead of <p>
. In Catalan it's < h4>
instead of <h4>
. This should be easy to tidy up in the translated string, I can do that.
Going forward, I'll add into my automated tests a check for < and > to try to pick these up.
Edit: I went ahead and built the test, found the same issue in Russian, and another issue where GVE doesn't work at all when French is selected. I've updated the translations in POEditor to correct these.
These translation changes are now merged into the main branch, so I will close this.
When using the poeditor.com translation system I can still see the folowing minor translation issues:
</p>
" instead of "</p>
" (superfluous space)When using the poeditor.com translation system I can still see the folowing minor translation issues:
* GraphViz instead of Graphviz
I've updated this in a couple of spots I found the term has it, but honestly this is a hard thing to track down as POEditor seems to only have case-insensitive search. We can search the .PO files, but then there is a bit of back and forth getting them updated. I think this is feasible, if time consuming, so I will try to do this sometime soon.
* "` </p>`" instead of "`</p>`" (superfluous space)
Same as above, a bit tedious to fix, but I will try to work out how to bulk update this. It would be nice if POEditor had a way to export and import all languages at once (for a quick find and replace) but as far as I am aware this is not possible, I have to do it one language at a time (exporting all seems to be on their backlog as a requested feature they are working on, but has been this way for years).
* "colour" instead of "color"
Is this specifically within the US English language? I can't find any instances of "colour" in US English, and "colour" is a valid spelling (except in US English). As per Grammerly:
When choosing between color and colour, keep in mind that both spellings are correct. The shorter one, color, is the preferred spelling in the United States. The rest of the English-speaking world uses the longer form, colour.
Is this specifically within the US English language? I can't find any instances of "colour" in US English, and "colour" is a valid spelling (except in US English).
In my opinion the language used in the code itself should be US English. So the source text in poeditor.com should be US English. At the moment "color" and "colour" are both used in the code. But this is not important. And everybody will understand it.
I found more points:
I have proof read all German translations; so this translation is nearly finished (there are now only two help texts still to be done).
In my opinion the language used in the code itself should be US English. So the source text in poeditor.com should be US English. At the moment "color" and "colour" are both used in the code. But this is not important. And everybody will understand it.
I tried searching on the internet about this, and it seems people are very opinionated on such things. Some are adamant that since programming languages are written in US English, so too should code. Others say they always code in UK English because that's what they speak. There are many more arguments one way or the other.
Our code base is pretty split. 520+ instances of "colour" and 150+ of "color" (not including the translation files). The code is still very disjointed, but parts are getting cleaner and better organised over time. Whether we use US or UK English, we should be aiming for consistency over the long term.
It certainly seems it would be easier to get it consistent as "colour", and the term "colour" also appears a few times in the names of settings used for saving the settings, where "color" doesn't show here at all (most use the shortened version "col"). Changing the names could stop some settings from loading properly. This isn't really a good argument though as it should be easy enough to work around.
If there's a strong argument for using US English, we can make that the aim. Otherwise, I will instead work towards standardising as UK English, as this seems a smaller task.
I found more points:
* there is still "3" instead of "3"
I think these are in no-longer used translations. I've removed them, but there are still other not-used ones. This is because I have merged settings together, and didn't want to delete them before translators have a chance to copy them into the merged ones. The translations are in the git history, but I presume not all translators are comfortable navigating this. I will leave them another week or two, then try to clear them out.
* "Shape" does not translate
This should be fixed once I've merged in my recent pull request, I'm just still adding to it as I've picked up a few things with testing.
* help text for "max generations" explains ancestor but not descendant generations
Hmm, I think I figured it was doubling up the explanation when the fields effectively do the same thing for their respective settings. Do you think I should have the same thing copied for descendants, with the example changed to give the example for descendants?
I agree with everything you said.
I don't like to have the max. generation help text be duplicated. But an additional sentence that the same is valid for the max generations of descendants.
In the general help text about "Help" there is a sentence about the symbol ⛶ (full screen). I'm mising a sentence after that sentence about the search symol and the search function. The next paragraph about using the clippings cart should be seperated by </p><p>
.
I've made these adjustments. Somehow I missed your second comment so have added that in a second pull request.
Once there are translations I'll update these. I realised I also haven't done the English ones so the extra sentence about the search won't show just yet. I'll give everyone a chance to update translations then update the translation files all in one go, rather than doing a third pull request in a row :slightly_smiling_face:
There are several non-balanced HTML tags in the translation code visible (like opening and not ending or ending but not opening
). In general I would prefer not to see them at all (then you have to cut the translation string into pieces) or to see both of them (then you have to move the missing HTML tags into the string).
Especially there is a problem in the translated help text (i) for "Treatment of source individual":
<p>
visible< h4>