issue-#174 fixing resource keys in StdLinks

User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

issue-#174 fixing resource keys in StdLinks

Post by Josef Templ »

Following the suggestion of Helmut I have created this issue for fixes with StdLinks resource keys.
Some keys are (1) wrong and (2) missing in the Strings resource file.
Some keys use the pattern "#StdLinks:..." instead of "#Std:...".

Note that issue-#173 must be finished first in order to avoid a merge conflict.

- Josef
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#174 fixing resource keys in StdLinks

Post by Josef Templ »

invalid resource keys have been fixed and missing keys have been added to Std/Rsrc/Strings file.

Please see the diffs at https://redmine.blackboxframework.org/p ... b1d27d4c76.

- Josef
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue-#174 fixing resource keys in StdLinks

Post by Robert »

A curious inconsistency between the use of CamelCase and "Words with spaces".

I think your approach was "Minimal change", but maybe consistent use of camel case is better? The current approach hides when the Strings file has missing keys (which may or may not be a good thing).
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#174 fixing resource keys in StdLinks

Post by Josef Templ »

Robert wrote:A curious inconsistency between the use of CamelCase and "Words with spaces".

I think your approach was "Minimal change", but maybe consistent use of camel case is better? The current approach hides when the Strings file has missing keys (which may or may not be a good thing).
Right, my approach was to not change any keys, just to fix the wrong subsystem prefixes.
However, for the case of the wrong prefixes it could be argued that changing the keys would not
introduce any incompatibilities. So this is an option indeed and an improvement, I think.
'Create Link' would for example be changed to 'createLink'.

The problem is with correct keys. Should they also be changed to start with lower case?
Those include: Link, Target, and LinkChange.
The latter key seems not to be used in practice, so it may be changed as well.
Changing 'Link' to 'link' and 'Target' to 'target', or not, that is the question.

- Josef
Zinn
Posts: 476
Joined: Tue Mar 25, 2014 5:56 pm
Location: Frankfurt am Main
Contact:

Re: issue-#174 fixing resource keys in StdLinks

Post by Zinn »

Should we use camelCase or normal Words with spaces (normal sentence)?
This question arise on all Strings resources and mixed up in a lot of places.

Most entries in strings are messages for the user. So I prefer to use words with spaces. It is also better readable when the Strings file is missing.

Should Strings entries sorted alphabetically or in order by topic of use (module and forms)?
This is also mixed up in both ways.

- Helmut
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#174 fixing resource keys in StdLinks

Post by Josef Templ »

Zinn wrote:Should we use camelCase or normal Words with spaces (normal sentence)?
This question arise on all Strings resources and mixed up in a lot of places.

Most entries in strings are messages for the user. So I prefer to use words with spaces. It is also better readable when the Strings file is missing.

Should Strings entries sorted alphabetically or in order by topic (module or forms) of use?
This is also mixed up in both ways.

- Helmut
These are very fundamental questions that cannot be completely resolved within this issue, I think.
Nevertheless, here are some comments from my side:

> Most entries in strings are messages for the user. So I prefer to use words with spaces. It is also better readable when the Strings file is missing.

The key in a Strings file should never be missing. If it is missing, I would consider this a bug.
If keys are distinguishable from values, it is easier to find such bugs.
Single-word keys in camelCase are a means to distinguish keys from values. They are usually also a bit shorter than the values.
I would, however, not go as far as changing all keys now but only consider the keys relevant for this issue.
I would strongly recommend to stick to the rule that all keys should appear in the Strings file because this makes it possible to
localize (translate) the Strings file without inspecting all modules, dialogs, etc.

> Should Strings entries sorted alphabetically or in order by topic (module or forms) of use?
I would prefer a grouping of keys that in some way are logically related, for example the
keys of the StdLinks module in the Std Strings file.
A practical advantage is that a diff is not spread across the whole Strings file, at least this holds for this issue.
The keys are sorted internally anyway, so there is no big speedup to be expected except that the sorting may be slightly faster.

- Josef
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue-#174 fixing resource keys in StdLinks

Post by Robert »

Josef Templ wrote:... So this is an option indeed and an improvement, I think.
'Create Link' would for example be changed to 'createLink'.
I was not thinking about the case of the first letter; I was thinking that "Create Link" would be changed to "CreateLink" to be similar to "LinkChange".

I now think that this could turn into a long discussion with very little real benefit, so it is best to stay with the "minimal change" approach.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#174 fixing resource keys in StdLinks

Post by Josef Templ »

Now I am also remembering why I thought that the 'key = value' approach would be 'more compatible'.
Imagine the russian translation by Ivan.
It does not contain the new StdLinks keys because they were not in the Strings file before.
With the key = value approach, the russian translation would return the key (= value) as a readable text in english
instead of the key. This is the same behavior as it was before and in that sense it is 'more compatible'.
This is only relevant, of course, if the new version is using the old translation, a precondition that is very questionable.

- Josef
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#174 fixing resource keys in StdLinks

Post by Josef Templ »

Robert wrote:
Josef Templ wrote:... So this is an option indeed and an improvement, I think.
'Create Link' would for example be changed to 'createLink'.
I was not thinking about the case of the first letter; I was thinking that "Create Link" would be changed to "CreateLink" to be similar to "LinkChange".

I now think that this could turn into a long discussion with very little real benefit, so it is best to stay with the "minimal change" approach.
Coming back to our original issue, for me any version is OK.
- as it is, i.e. key = value, e.g. Create Link
- with keys in the form CreateLink
- with keys in the form createLink

It is a small change to adapt it to another version but it should not be
mixed with the feature discussion going on now. This is a bug fix issue.

- Josef
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue-#174 fixing resource keys in StdLinks

Post by Robert »

Zinn wrote:I have a little extension ...
Helmut: Although I like this suggestion I agree with Josef; this is a separate issue, and as a new feature I regret that it has missed release 1.7.1.
Josef: I think we can go with your original diff; I see no big advantage in changing it.

If we can get this issue resolved, and incorporate the "Window ghosting" fix, I think we can then release issue 1.7.1 stable.
Post Reply