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
issue-#174 fixing resource keys in StdLinks
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#174 fixing resource keys in StdLinks
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
Please see the diffs at https://redmine.blackboxframework.org/p ... b1d27d4c76.
- Josef
Re: issue-#174 fixing resource keys in StdLinks
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).
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).
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#174 fixing resource keys in StdLinks
Right, my approach was to not change any keys, just to fix the wrong subsystem prefixes.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).
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
Re: issue-#174 fixing resource keys in StdLinks
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
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
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#174 fixing resource keys in StdLinks
These are very fundamental questions that cannot be completely resolved within this issue, I think.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
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
Re: issue-#174 fixing resource keys in StdLinks
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".Josef Templ wrote:... So this is an option indeed and an improvement, I think.
'Create Link' would for example be changed to 'createLink'.
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.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#174 fixing resource keys in StdLinks
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
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
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#174 fixing resource keys in StdLinks
Coming back to our original issue, for me any version is OK.Robert wrote: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".Josef Templ wrote:... So this is an option indeed and an improvement, I think.
'Create Link' would for example be changed to 'createLink'.
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.
- 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
Re: issue-#174 fixing resource keys in StdLinks
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.Zinn wrote:I have a little extension ...
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.