Lazarus
Miscellaneous => Suggestions => Topic started by: Avishai on July 04, 2012, 07:47:44 pm
-
This is just an idea that I have and would like some opinions. I have not tried to do this so there could be huge problems to make it work.
The Idea:
For Controls that have Text, a new property could be added for 'Language' with the default set to the programmer's Language. It could be used to:
1. Set the correct Keybord Language on Entry to the Control. The user could still switch with the normal Keybord switch in run time.
2. In the Property Editor, if BiDiMode IsLeftToRight, only LeftToRight Languages would be listed in the DropDown List, and if BiDiMode IsRightToLeft, only RightToLeft Languages.
3. Set the correct Sort routine for Controls that have Lists. The last time I checked, it seemed that each Control had a different default Sort Routine and all of them failed for many Languages. So the programmer had to do extra work for this very basic task.
4. I do not know enough about Far East Languages to make any suggestions.
It might be a good idea to add a property SetKBD: Boolean
-
Are you saying that you are using multiple keyboard layouts in a form - presumably one for English and one for Hebrew and/or Arabic?
Do other programming environments have similar facilities? I would expect functionality like that to be handled by the operating system, really... but I have 0 experience with RTL, so I'm probably wrong...
As for the sorting: apart from the obvious suggeston to unify the sorting routines as much as possible (to be able to override them in one spot): using some property to override standard sorting sounds like a good idea....
However: shouldn't sorting be specified by localization in general? No idea how Delphi and Lazarus do this now (I am myself only now discovering the joy of accented characters and other alphabets... ;)... but I would imagine this sorting behaviour to chnage automatically with localization.... unless explicitly overridden in the property editor (because something needs a certain fixed sorting rule).
-
Hi BigChimp. I have several apps that use multiple Languages. I don't think it's that uncommon. One example a government office Form. A person's name must be in both Hebrew and English. So I have 'Avishai' and 'אבישי'. But it could be Spanish and Russian or any other lang.
Sorting is one of the most basic operations in computing. I think it all started with punchcards if you remember those things. Yet in Lazarus (and I think most programming tools) sorting is not so 'basic'. According to Blaazen, Croatian and many other languages have special sorting rules. Lazarus can sort most langs, but you have to do extra work if it's not the 'standard' sort and it's not easy to figure out which sort method to use. I still haven't found the right one for Hebrew. You should see the mess I get with Hebrew and TStringList 'standard' sort! It shouldn't be that way for such a basic task.
Locale doesn't really work too well. Many people must switch between different langs on a routine basis and it isn't practical to change Locales just to get proper sorting, if that even works. But I haven't tried it so I don't know. Maybe I should. Imagine working at an International travel agency.
As for exploring new languages, good for you :)
-
I did a 'proof of concept' derived from TEdit and it worked perfectly for setting keyboard language. One was set to Hebrew and another set to English. Keyboard switching was automatic. I haven't tried Sorting yet. Of course, to make this work globally, it would take a lot more work. I think you would have to start with TApplication.Lang and TControl.Lang + TControl.ParentLang.
-
I just tried switching Locales and the sort order did not change. For Hebrew the default sort was still a complete failure. This is probably true for any language that does not use the default sort order.
-
If there was a 'TApplication.Lang' property, maybe 'Translations' could default to the Language setting as well. So an English speaking programmer could use English to create a Menu for example, and set Application.Lang:= 'RU' and the Menu would be translated to Russian along with the rest of the Application.
-
1) Keyboard mapping. Imho, that is a task, that must, be left to the OS.
I do not know, how you have done your proof of concept?
But just translating something like "a" becomes "whatever" will not work.
People may have different keyboards connected, which can have totally different layouts, and even make your mappings differ. And then there are dead keys, that will do nothing, unless combined with the next stroke. e.g one key says "accent" and the next "a", which results in an accented "a". OR try the IME for Japanese and Chinese
And you can't even be sure about one single language. I use a uk keymap. But dvorak. So even it produces the keystrokes for uk English, it has a different layout.
There are also special input methods for disabled people, which may again be different...
If you need to change the input for a specific TEdit, then you need to tell the OS, and let the OS handle that.
Afaik the way to do this, is to communicate with the IME (Input method manager). That exists on most OS.
On windows the user can set global hotkeys (outside the app), to change the layout. But afaik, the app can change certain IME settings too.
------------
2) Sorting:
Yes it would be good to have a global hook, for all string comparisation. Not sure, maybe it exist....
As for the rest, I think implementing custom sort orders, should be left to the user.
In any way it is not done by language, but by "collation". Alone the German lang, has several sort orders...
And knowing that, within one application, different places could use different collations of the same language.
-
Thanks Martin_fr. It's always good to get input from you.
Presently, when I need to switch Keyboards from one control to the next, I use
const
LangHeb = $40D;
var
BiDiKeyboard, NonBiDiKeyboard: LongInt;
procedure SetLang(AForm: TForm);
{ Load Keyboard Language - Windows ONLY! }
begin
{$IfDef Windows}
case AForm.ActiveControl.IsRightToLeft of
True : ActivateKeyboardLayout(BiDiKeyboard, 0);
False: ActivateKeyboardLayout(NonBiDiKeyboard, 0);
end;
{$EndIf}
end;
initialization
NonBiDiKeyboard:= GetUserDefaultLangId;
BiDiKeyboard:= LangHeb;
This is enough for my needs because I usually only have to deal with two languages. But it doesn't take much to add other languages. This is only good for Windows, but I have read that the same thing can be done for Linux and Mac.
-
{$IfDef Windows}
case AForm.ActiveControl.IsRightToLeft of
True : ActivateKeyboardLayout(BiDiKeyboard, 0);
False: ActivateKeyboardLayout(NonBiDiKeyboard, 0);
end;
{$EndIf}
Ok, so that leaves it to the OS, which is correct.
Only question is, if something like dvorak exists. Because then the keys for the same language, and same bidi setting, are on different locations.
So unless you know, the user has a standard keyboard, the user should maybe be able to configure the required language?
There are more things I do not know.
If you use Japaneese, then there is a special IME, and it knows different modes. I do not know, if or if not that code will reset (or should reset) those....
-
Haha! Yes, it is a very complicated process. My little routine is very specific and a bit specialized. And of course, the keyboard must already be installed. But I think with some work Lazarus might be able to help make it a bit simpler.
Sorting is really kind of a major issue in my opinion. Lazarus has several custom sorts already in code, but the programmer has to know which one to use and they must manually override the 'standard' sort. Again, I think it could be made simpler.
But the key to both keyboard and sort issues depends on knowing what language you are dealing with for each control. That is why I started this post.
Lazarus and FPC are such fine tools, and having a truly international user base gives it a strength that most tools do not have.
-
Wow! I may be the last to know this, but I just discovered that TListBox doesn't even sort English correctly! I added the English Alphabet in UpperCase and then in LowerCase and set TListBox.Sorted:= True; I did the same with TComboBox and the Sort was consistent, but TListBox sorted Upper,Lower - Lower,Upper - Upper,Lower... %)
-
It simply looks, like it sort case insensitive.
So "A" and "a" is the same, and they have therefore no specific order.
I can think of 3 sort results:
1) letter, then case (upper, then lower)
Age, abort, Bold, bend
2) case, then letter
Age, Bold, abort, bend
3) letter, case ignored (upper, then lower)
abort, Age, bend, Bold
of course, in the 3rd case, items that are identical, except for casing, will be in random order, as case is 100% ignored
-
What you say is true, but why is it that TComboBox can get it 'right' and TListBox can not? Of course they both can, but you have to use a custom sort. This seems very strange.
Luckily, Hebrew does not have 'Case' so it is not a problem, but I still have to use a custom sort anyway.
Edit: If all of the controls that need to be able to sort simply pointed to a CustomSort instead of having there own unique sort at least their sort be be consistent. Then the TControl.Lang property could be used to selet the CustomSort.
-
Well, I don't know the concept behind...
I would have thought thy would have an OnCompareItems. But it looks not... Then the actual sort is in the widgetset. which means, it may even be OS dependent.... But as I said I do not know the answer to that
-
I looked at the code for TListBox and TComboBox and they each have there own unique sort code 'built in'. I think this may be true for other Controls as well. If this is true, it really makes no sense. I'm sort of new to Lazarus so I may be completely wrong about this. Anyway Sorting is a very basic method and the language is what must drive the sort method. In my opinion, there can not be such a thing as a 'default' sort method. It must be Language specific and that is one of the reasons that I think it would be worthwhile to add TControl.Lang. If you start with TApplication.Lang then that gives a 'default.Sort' to all children.
-
OK. I now have a Sort for TStrings that works for Hebrew.
I also have a Sort that I was told works for Portuguese.
It would be nice if some one could check it. I don't know Portuguese.
I know that others have Sort routines for other languages and maybe could share.
My code is not the best, but it's working.
I have tested with TListBox, TComboBox and TMemo.
I added the Hebrew alphabet in random order into each control and a button to Sort each list.
-
I saw your 2 reports on Mantis. While I have no intend to vote for or against it, I do not think that changing the sorting that way makes really sense.
Consider the following words: Add, ball, Can, dot
According to case sensitive, they will be sorted: ball, dot, Add,Can.
That is probably unwanted in the majority of cases. And if they are sorted none case sensitive, then "Add" and "add" are the same word (and a stringlist, if set to reject duplicates) would reject them.
Sorting equal items is normally not possible. They need an additional criteria.
In a Grid, that can be another column. But it could also be something like the original order, or something, that is not available to the component, data stored elsewhere in the app.
----------------
Now having said that, I can of course think of what you might aim for:
Sort case-insensitive, and only for equal items consider the case.
But that is exactly what I said: It's a case insensitive sort, with use-case specific extra criteria.
Why should the case of identical items be more important than the order in which they were originally added? Or in a grid the content of the next column?
Further more, in a grid, if the word "add" occurs several times, and all of them all lowercase, then they can again not be sorted. But the random result will be seen in the other columns.....
It depends on the application. The generic sort in the LCL can not know what is the most appropriate sort case.
--------
And further more none of that solves your language (collation) requirements.
This shows, that whatever sort the LCL will provide, it will always fit only a small part of the use-cases.
But if most applications must anyway provide there own sorting, then why should the default be made more complex than needed?
The only way to answer that in a positive manner is, if the new default would match a significantly higher amount of use-cases.
- I do not thing, that the special case-for-equal-items only will do that
- Adding a way to provide a (optional) collation for sorting might help (but I am not sure, it can solve the same-word-diff-case issue...
------------
Having said all that... I do not know what the best way is.
Something can probably be done. But before going after one small part of it, the overall picture should be considered.
-
"Something can probably be done. But before going after one small part of it, the overall picture should be considered."
I totally agree. Sorting is not an easy task. Firstly, it is Language Specific. That is why I started this discussion. I have some ideas and I am still developing new thoughts. But I think that Sorting is an important issue for computing.
I think the thing that bothers me most is that it seems that each control has it's own unique sort method, so you get different results for each control if it's not 'English Sort'. I know that you are far more familiar with Lazarus code that I, but at least on the surface, it would seem like there would be one central Sort method with a decision tree that would be called by all controls that need to Sort. Even if it's the wrong Sort, at least it's the Same Sort. But I may be wrong about all of this. I am still very new to Lazarus/FPC. I make new discoveries every day :)
I wish I knew more about other languages. I can only test for English and Hebrew. That doesn't made a good test.
And then there is the issue about programmaticly activating different Language Keyboards.
Example: You are in a TMemo. The Hebrew Keyboard is active. You need to change Font Name in a FontComboBox. Click on FontComboBox and start to type. You are still in Hebrew so nothing matches. Oops. Toggle the Keyboard. Delete. Select Font. Back to your memo and start to type... You are not in Hebrew. Delete. Toggle Keyboard.
-
Oh By the way. When TStringList.CaseSensitive:= True you get:
Able,apple,Arrive,cat,City,count...
So it groups 'aA' then 'bB' as I would expect.
-
One might consider introducing a public CompareFunc property for these controls, where user can do something like:
function MyCompareFunc(Item1, Item2: Pointer): Integer;
begin
..
end;
...
MyListBox.CompareFunc := @MyCompareFunc;
MyListBox.Sorted := True;
..
And the sorting algorithm of MyListBox now uses MyCompareFunc() instead of it's default compare function for items.
Bart
-
Bart, that would be a step in the right direction. It's clumsy the way it is now, but doable. Adding CompareFunc would help.
-
In LazUTF8.pas there are some routines that are interesting.
function UTF8LowerCase(const AInStr: string; ALanguage: string=''): string;
{ It uses ALanguage to decide how to do LowerCase. }
procedure LazGetLanguageIDs(var Lang, FallbackLang: String);
procedure LazGetShortLanguageID(var Lang: String);
{ Gets the User Locale. }
I haven't really studied at the code to try to see what really happens, but my guess is that at some point, LazGetLanguageIDs gets called and the 'Lang' is used by UTF8LowerCase based on Locale by default.
But you can call UTF8LowerCase and give it any valid 'Lang' if you need to LowerCase a string in another language.
So the idea of having a 'property Lang: String' and 'property ParentLang: Boolean' could be used with these routines to make LowereCase almost automatic.
as for Sorting, something similar could be done.
procedure Sort(AList: TStrings; ALanguage: LongInt);
begin
case ALanguage of
LANG_ENGLISH: DoEnglishSort; // LANG_ENGLISH is in Defines.inc with all the other Langs listed
LANG_FARSI: DoFarsiSort; // But LANG_ENGLISH isn't enough. You need the full LanguageID
LANG_GERMAN: doGermanSort;
...
end;
end;
I think the hardest part would be finding the right Sort method of each language. The are A LOT of languages.
-
Bart, along with your code addition, it looks like it would also need 'property SortAscending: Boolean:= True;' so that you can Sort Ascending or Descending. So my Hebrew Sort looks like:
function SortHebrew(List: TStringList; Index1, Index2: Integer): Integer;
{Hebrew}
begin
Result:= UTF8CompareStr(List[Index1],List[Index2]);
if not SortAscending then
Result:= -Result;
end;
Of Course all of this can be done with no addition to Lazarus code, but it would make things better (IMO) if it were a part of Lazarus so that not everyone has to re-invent the wheel.
-
Bart, along with your code addition, it looks like it would also need 'property SortAscending: Boolean:= True;' so that you can Sort Ascending or Descending.
For any TStrings descendant you can use it's CustomSort(@MyCompareFunc), where MyCompareFunc is of type TStringListSortCompare.
But I agree that it would also make sense to have a SortOrder (soAscending, soDescending) property for any class that offers sorting for strings.
It would probably be a major incompatibility with Delphi though.
Bart
-
But I agree that it would also make sense to have a SortOrder (soAscending, soDescending) property for any class that offers sorting for strings.
It would probably be a major incompatibility with Delphi though.
@Bart: could you elaborate on that? How does Delphi do sorting for their controls for non-English languages?
-
@BigChimp: I think because Delphi has been Ansi Chars in the past, it did not need to do anything special. In Delphi 6, it simply sorts to Char Code.
-
@Avishai: I know Delphi used to use AnsiChar, but it's been Unicode-enabled for a few versions now. I would expect language specific sorting to go with that.
I asked Bart what Delphi was doing because he said a SortAscending property would be incompatible... well, then I suggest we emulate how current Delphi does things (as long as it takes different languages into account and makes sense).
-
@Bart: could you elaborate on that? How does Delphi do sorting for their controls for non-English languages?
My Delphi is very old (3.0), but I suspect Delphi doesn't have this, or else it would have been reported as a missing property/method some tim ago?
Bart
-
As far as I understand from the Delphi online help (I don't have a new Delphi either), it should sort by default based on the OS locale, so it should take different sort order into account. Couldn't find a definitive link that clearly indicates how etc.
Confirmation by somebody who actually uses a newer Delphi would be nice though...
-
It probably uses some system library call to compare strings (WideStrings that is), which might be locale dependant 9like StrCmpIW perhaps?).
Bart
-
Well, maybe my idea isn't so crazy after all. I was looking for a solution and found some stuff about MicroSoft VB and C#. I have no way to confirm this, but from what I read, you are able to set 'Language' at least at the 'Application' level. I don't know if you can set it at the component level. There is a very simple method of creating resource strings right in the IDE and I 'think' there is a 'Localizabe' property for controls. So it appears that when you change the 'Language' all of your Forms are Translated. It also activates Language Keyboards and selects Sort methods. As I said, I have no way to confirm any of this. But if any of this is true, then MS VB and C# are way ahead of Lazarus when it comes to languages. Oh yes, Forms also have a 'RightToLeftLayout' property that will mirror the Form for RightToLeft Forms. These are things I can only dream about with Lazarus, but I'm a 'Pascal man' so I'm not leaving Lazarus.
-
You mean there are other languages besides English? Next you will be telling me there are other currencies than the US Dollar... :o
-
Hahah! You may not believe this, but there other calendars too ;) And then there's those crazy countries that drive on the 'wrong' side of the road or think 3 feet makes a yard.
-
No way! :o
I need to get out more...
-
Well, maybe my idea isn't so crazy after all. I was looking for a solution and found some stuff about MicroSoft VB and C#. I have no way to confirm this, but from what I read, you are able to set 'Language' at least at the 'Application' level. I don't know if you can set it at the component level.
Sorry if I'm being too obvious here or if this has been raised before, but how do current Delphi versions deal with this? If it's any good, we could emulate it and gain compatibility at the same time...
-
I wish I knew, but I quit upgrading at Delphi 6. I tried to find something about current Delphi but came up empty.
-
You mean there are other languages besides English? Next you will be telling me there are other currencies than the US Dollar... :o
<sarcasm on>
You live in the US? Then you should know. Not sure what language you use, but it isn't English, according to a quote from "My fair Lady":
"There even are places where English completely disappears. Why, in America they haven't used it for years!"
-
Yes. USA. And that quote is very accurate...
-
Well, it looks like current Delphi does have at least some of these features.
http://www.delphibasics.co.uk/Method.asp?NameSpace=System.Globalization&Class=CultureInfo&Type=Class&Method=GetCultures
http://www.delphibasics.co.uk/NameSpace.asp?Name=System.Globalization&Part=CultureInfo
-
Well, it looks like current Delphi does have at least some of these features.
http://www.delphibasics.co.uk/Method.asp?NameSpace=System.Globalization&Class=CultureInfo&Type=Class&Method=GetCultures
http://www.delphibasics.co.uk/NameSpace.asp?Name=System.Globalization&Part=CultureInfo
Those are .NET specific as far as I know there is nothing similar for win32/64 and since delphi.net has been dropped in favor of Oxygene that is an inaccurate statement. I have no idea my self how delphi supports I"ll have to locate my d2007 installation and take a look. I'll try to post more info later.
-
I think all this recent talk about whether Lazarus Install should default to English or not, Adding a Setup Dialog to Lazarus Installation so the user can select a Language and so on gives a lot of credit to the idea of adding a Language property to controls, starting from TApplication.Language. Language really is an issue, even for the Lazarus IDE.
-
Does anybody have a modern version of Delphi that could check to see if it has language support? I tried to get the Trial version, but my country is blocked by Embarcadero from getting the Trial version. Same for Microsoft.
-
I just found a very interesting article about MicroSoft Globalization/Localization and Sorting regardless of Language. Naturally it's only for Windows.
http://msdn.microsoft.com/en-us/goglobal/bb688122
-
I think the strongest argument in favor of adding 'Language' to controls is the sorting issue.
Example:
You write a program in English that has ListBoxes and ComboBoxes with predefined strings in them. You set the Sort property to true. Everything looks good. Then you give a copy to a Russian and another to a Greek. They report back that the strings are translated correctly, but are sorted in RANDOM order. So you do your research and find the right sort methods for Russian and Greek. But how do you release your program to the general public??? Do you have to do this for EVERY LANGUAGE!? And how do I know if I'm using the right method for a language I can't read??? Arabic is a beautiful written language, but I can't even tell where a character begins and ends.
By adding a Language property and a decision tree for sort methods based on Language Number that can be worked on by the entire Lazarus community, you would be able to simply say "Sort" and it wouldn't matter if it was running on a Japanese or French Locale.
I only recently discovered that the "Standard" sort methods are not case sensitive which introduces yet another form of randomness. There is a way around it of course, but it seems odd that a seemingly simple task of sorting a list has to be so complex, including numeric sort.
Of course Activating the correct Keyboard Language is an issue as well, but maybe not a severe as sorting.
-
I think the strongest argument in favor of adding 'Language' to controls is the sorting issue.
I've never heard of a "Language" property at the control level. Can you cite a single UI framework that does it that way?
For example, if you look at Apple's internationalization guidelines, you see that sorting based on locale is the developer's responsibility:
https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPInternational/Articles/InternatAndLocaliz.html
Thanks.
-Phil
-
Thanks Phil. I've been trying find out what C# and VB do. I have read that they have a Language property, but I can't tell if it's only at the Application level, or if it's on the component level. I wish I knew.
To me, it's a bit absurd to think that a developer has to consider finding just the right sort method for every possible locale. That takes a big team that knows a lot of languages. Lazarus has a big team.
But take a look at Lazarus LowerCase routine. It's HUGE! Some one, or a lot of some ones, took a lot of time and trouble to come up with that. UpperCase is the same way. Such a very simple task until you realize the complexity of it.
-
To me, it's a bit absurd to think that a developer has to consider finding just the right sort method for every possible locale. That takes a big team that knows a lot of languages. Lazarus has a big team.
I would expect this information to be available from the OS. For examle, on Mac, each locale is associated with a "collation identifier" - that's for localized string comparisons.
Thanks.
-Phil
-
That doesn't seem to be the case with Lazarus. If I use the 'Standard' sort (i.e. TStringList.Sort:= True) on the Hebrew Language, I get a total failure as far as sort order on both English and Hebrew Locales.
Also, having more than one Language in a program isn't that uncommon, so one Sort Order doesn't always work. Up until recently I was writing only for English and Hebrew, but now I am trying to write for UserLocale + Hebrew and I have to use different sort orders. It isn't working out too well.
Right now I'm reading MicroSoft's Globalization whitepaper on Sorting (again) trying to make some sense of it. But knowing the Language is the key. If that changes from one control to the next, then what?
http://msdn.microsoft.com/en-us/goglobal/bb688122
-
That doesn't seem to be the case with Lazarus. If I use the 'Standard' sort (i.e. TStringList.Sort:= True) on the Hebrew Language, I get a total failure as far as sort order on both English and Hebrew Locales.
Design a compare function per your locale (using OS info, if necessary), then pass this into TStringList.CustomSort.
Thanks.
-Phil
-
I already do that. But that's kind of the point of why I'm asking the question. How can I design a compare function if I don't already know what Locale it will be running on? I can get the Locale at run-time, but even if I wanted to, I can't write a function for every Language. And if the app is multi-lingual?
Some time ago I wrote an app for a hotel. The guests could pick their language by clicking on a flag. The Locale never changed but the display/entry changed to their language and the correct Keyboard was loaded.
-
I already do that. But that's kind of the point of why I'm asking the question. How can I design a compare function if I don't already know what Locale it will be running on? I can get the Locale at run-time, but even if I wanted to, I can't write a function for every Language. And if the app is multi-lingual?
Write the compare function based on information it gets from the OS for the specified locale, whether the system locale or one the app (user) specifies.
Thanks.
-Phil
-
That only works if you know which locales you will be working with, or you write one for every locale. That might be an option on a huge money project, but not for for small projects. And Locale doesn't address multi-lingual apps. It gives you only one sort method.
-
That only works if you know which locales you will be working with, or you write one for every locale. That might be an option on a huge money project, but not for for small projects. And Locale doesn't address multi-lingual apps. It gives you only one sort method.
A "locale" is a language + region designation. You should be able to retrieve information from the OS about any locale you want.
Thanks.
-Phil
-
I have no problem getting the information. But what can I do with it? There is no Lazarus 'SortJapanese' routine, so you have to know in advance that you need such a sort method. If you write a program that you want to distribute globally, that would mean having a sort method for every locale. I have no idea what sort order Finland uses but I am sure that one of the Lazarus users does. TStringList.CustomSort:= ?
case TStringList.Lang of
LangEN_US: SortEn_US;
LangFr: SortFrench;
LangRu: SortRussian;
LangHe: SortHebrew;
...
end;
If it can be done for LowerCase, it can be done for Sort, but it shouldn't be driven by Locale. It should be driven by Language. Right at the moment, my Locale is Hebrew. But as you can see, I'm working in English. Imagine if having a Hebrew Locale meant that I could only type Hebrew. That would mean that I couldn't use Lazarus because FPC doesn't speak Hebrew. Multi-lingual is a fact of everyday life for most of the world.
-
It should be driven by Language. Right at the moment, my Locale is Hebrew. But as you can see, I'm working in English. Imagine if having a Hebrew Locale meant that I could only type Hebrew. That would mean that I couldn't use Lazarus because FPC doesn't speak Hebrew. Multi-lingual is a fact of everyday life for most of the world.
Option to display a list of locales that your app supports. User chooses one. Load that locale's settings from OS. Etc.
At startup, default to system's locale; once user selects locale, save this in app's preferences and use it in subsequent runs of the app.
Thanks.
-Phil
-
I have that option in some of my programs, but Locale doesn't supply a sort order, at least not in Lazarus. As I said, if I have a TStringList with Hebrew words, I get the same wrong 'Standard' Sort no matter what Locale I use. That means I have to supply a CustomSort.
( I don't know if the SortLatin is good or not )
function SortHebrew (List: TStringList; Index1, Index2: Integer): Integer;
{ Hebrew }
begin
Result := StriComp(PChar(List[Index1]), PChar(List[Index2]));
end;
function SortLatin(List: TStringList; Index1, Index2: Integer): Integer;
{UTF8Compare - Portuguese...}
begin
Result := WideCompareText(UTF8Decode(List[Index1]),UTF8Decode(List[Index2]));
end;
Edit: Also, TListBox and TComboBox don't have a CustomSort. I have to copy the Strings to a TStringList, Call a CustomSort and copy the strings back to the TListBox or TComboBox.
-
I have that option in some of my programs, but Locale doesn't supply a sort order, at least not in Lazarus. As I said, if I have a TStringList with Hebrew words, I get the same wrong 'Standard' Sort no matter what Locale I use. That means I have to supply a CustomSort.
That's why I'm suggesting that you get your locale info from the OS and that you use a custom sort per whatever your app's requirements are. Add a custom sort as needed for each language as you localize for it.
Remember that TStringList is not part of Lazarus, it's part of FPC RTL.
Thanks.
-Phil
-
Wouldn't this make more sense?
case TStringList.Lang of
LangEN_US: SortEN_US;
LangFR: SortFrench;
LangRU: SortRussian;
LangHE: SortHebrew;
...
end;
Edit: Wouldn't it be better if you could just say:
ListBox1.Lang:= LangRU;
ListBox1.Sorted:= True;
-
Edit: Wouldn't it be better if you could just say:
ListBox1.Lang:= LangRU;
ListBox1.Sorted:= True;
Why not just create your own subclasses of TListBox, etc. and add the properties and functionality you need?
Thanks.
-Phil
-
As far as I understand this problem can be split in 2:
1. non-English sort order is not supported out of the box, period
2. multilanguage forms (i.e. multiple controls with different languages) are not supported
I'd think point 1 is quite bad and should be addressed. Obviously, Avishai feels strongly about 2 - by addressing 1 we might have an easier fix for 2, too.
For problem 1: I agree with Avishai that sorting (whether that is based on locale or language) is something that could and should be provided by the compiler/LCL... that perhaps do a call to OS language-specific sorting functions (Win32 CompareString? as mentioned in Avishai's MSDN link).
Why? As he said, otherwise devs would need to reinvent their own sorting routines for all languages. Perhaps we'd get some forum thread where people share sorting code... fine... but why not add it to the RTL?
I really think it's worth it to look at how other development environments do it - I cannot believe e.g. C#+Windows or Objective C+OSX don't have facilities for this. Perhaps it's a good idea to look at how/if Mono provides this - we could have a look in the source code and have some idea if/how Linux OS calls are used.
Perhaps it's better to just raise a bug on Mantis such as "there's no language or locale dependent sorting in TStringList" with a link to the discussion here to get the devs to weigh in on if/how this could be done.
-
Thanks BigChimp, I always look forward to hearing your views on such things as this.
Each OS supported Language already has a numeric value (at least in Windows and I assume other OS's). So it seems to me that a simple (but long) case statement would work to select a sort method. That method could then be used by any control that needs to sort a list. The one exception that I can think of is SortNumeric, but that would be easy to add to the case statement (LangNumeric). I've experimented with this approach and it seems to work, but it's a very limited experiment because I don't know the correct Sort Order for many languages. Lazarus has a truly global user base. If we couldn't find some code that was already written that could be translated to Lazarus/FPC, I think it would not take long to collect Sort Methods from the Lazarus community to plug in to such a case statement.
And there's also the issue of activating the correct Keyboard. I do these things now, switch Keyboard and Sort Order on a control by control basis. But it took a lot of work and research, trial and error to get to this point and I'm still working on it. I know I'm not the only one that has to deal with this and I can imagine other people trying to figure this out and reinvent this same wheel.
I would love to get a chance to look at how other programming environments approach this. It's hard for me to believe that this isn't being handled in some way.
For Lazarus ListBox, ComboBox... Sorted:= true is a "one trick pony" :) And the worst part is that, if it is sorting non-English, you may get different results for each control. I know this is true for Hebrew. In Hebrew, ComboBox gives a different result for the same list depending on how many times you sort it :(
I took a look at Win32 CompareString but I haven't figured out how to use it yet. I tried Lazarus/FPC CompareStr, but it Sorted 'ABC abc'. That wouldn't work for me. At least TStringList.CaseSensitive gives 'aA bB cC'.
I haven't posted anything to BugTracker yet because I wanted to get some input from other people to see how they feel about it. It's been a mix. The developers have a lot of things to work on so adding something to that list doesn't seem like the best thing just yet. If and when we can come up with a coherent plan/design, then maybe we could present it to them.
-
I finally got a chance to take a look at VB. It was a very short look so my impressions may be wrong. But it looked like the Language Property was only at the Form Level. That was disappointing. I also didn't get a chance to see how it worked, but it didn't seem to activate the Language Keyboard as I had hoped. Maybe there's a setting that I didn't see.
VB had no problem sorting Hebrew or English correctly regardless of what Language was set, but I can't say for other Languages.
I did get one major surprise. VB has the Properties RightToLeft and RightToLeftLayout. If both are set to TRUE, the Form and Canvas are Mirrored to make a True RightToLeft Form at Design-Time. Left becomes Right and Right become Left. So when you say Left:= 10, it means 10 from the Right. This makes designing a RightToLeft Form just as easy as designing a LeftToRight Form without the huge amount a extra code and time needed finding workarounds in Lazarus. Now I understand why there are so few Middle-Eastern and North Africans using Lazarus.
I have the code to Mirror the Forms and other controls, but it only works at Run-Time and only with Themes turned OFF. When Themes are ON, TCanvas becomes corrupted and unusable. There is something wrong with the way Lazarus handles Themes. With the method I use, you have to design a LeftToRight Form and see it RightToLeft only at Run-Time. If anyone wants the code, let me know. I'll be happy to share and explain some of the strange workarounds that I have discovered.
-
I did get one major surprise. VB has the Properties RightToLeft and RightToLeftLayout. If both are set to TRUE, the Form and Canvas are Mirrored to make a True RightToLeft Form at Design-Time. Left becomes Right and Right become Left. So when you say Left:= 10, it means 10 from the Right. This makes designing a RightToLeft Form just as easy as designing a LeftToRight Form without the huge amount a extra code and time needed finding workarounds in Lazarus. Now I understand why there are so few Middle-Eastern and North Africans using Lazarus.
In Apple's Xcode designer, you do this with a "constraint" (probably similar to VCL/LCL Constraints property). But they introduce "leading" and "trailing" properties, probably to avoid "reversing" the meaning of left and right the way MS did. I would guess that the same design could then be used with both left-to-right and right-to-left.
"Leading and trailing are similar to left and right, but they are more expressive because they automatically mirror the constraint in a right-to-left environment."
I take that to mean that "leading" is the space to the left of the text starting point in l-to-r and the space to the right of the text starting point in r-to-l.
Perhaps what you need in the form designer could be handled by an expanded Constraints property.
More info here:
http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/OSX_Technology_Overview/CocoaApplicationLayer/CocoaApplicationLayer.html#//apple_ref/doc/uid/TP40001067-CH274-SW20
Thanks.
-Phil
-
I did get one major surprise. VB has the Properties RightToLeft and RightToLeftLayout. If both are set to TRUE, the Form and Canvas are Mirrored to make a True RightToLeft Form at Design-Time. Left becomes Right and Right become Left. So when you say Left:= 10, it means 10 from the Right. This makes designing a RightToLeft Form just as easy as designing a LeftToRight Form without the huge amount a extra code and time needed finding workarounds in Lazarus.
As I said, you might want to look into how the Mono framework - the open source variant of the Microsoft CLR - handles this. On Windows, it should support RightToLeft etc as well... perhaps there's interesting hints in there....
-
Thanks guys. I'll look into both. I just glanced at the Apple page. It looks interesting. I wasn't sure Apple even had Mirroring. I was told that there was no need in Apple, but you can hear anything. :)
As for Mono, I'm embarrassed to say I had never heard of it. :-[ That's one of the really great things about being in a community like this. You get to learn about all sorts of things you might never know about otherwise.
-
As I said, you might want to look into how the Mono framework - the open source variant of the Microsoft CLR - handles this. On Windows, it should support RightToLeft etc as well... perhaps there's interesting hints in there....
What's he talking about are properties in WinForms forms. Mono's WinForms support is deprecated, I believe, and most certainly _not_ cross-platform.
http://msdn.microsoft.com/en-us/library/system.windows.forms.form.righttoleftlayout.aspx
I'm not sure what the state of MonoDevelop's form designer is for WinForms.
Thanks.
-Phil
-
As for Mono, I'm embarrassed to say I had never heard of it. :-[ That's one of the really great things about being in a community like this. You get to learn about all sorts of things you might never know about otherwise.
A bit of Mono info from Laz wiki:
http://wiki.lazarus.freepascal.org/Using_Pascal_Libraries_with_.NET_and_Mono
Two companies that have had quite a bit of success in utilizing Mono are Xamarin (http://xamarin.com) and RemObjects (remobjects.com). However, their interest (and success) is primarily due to a focus on mobile, particularly iOS (see RemObjects news). Mono no longer has corporate sponsorship (Novell), so I'm not sure where Mono as cross-platform _desktop_ tool will end up.
Thanks.
-Phil
-
I guess I should say that I am not looking for a different programming environment. My only reason for looking at the others is to see 'how' and 'if' they support Human Languages. Lazarus isn't doing a very good job in that area yet and I would like to be able to help make it better. I have some ideas, but they aren't fully developed ideas yet.
The big hangup right now for RightToLeft is Themes and TCanvas. If that can be fixed, I already have the code to Mirror controls at design-time. I just can't use it because all TCanvases turn permanently black.
I also want to see if I can find out how VB is doing Sorts and if it can be correct without regard to Language. It worked for Hebrew and English so...
-
If that can be fixed, I already have the code to Mirror controls at design-time. I just can't use it because all TCanvases turn permanently black.
Not sure what that second sentence means. At design time? At runtime?
Thanks.
-Phil
-
OK I've been following this thread on and off and I'm not sure if I remember correctly but, I disagree in extending all the components (ee all Tcontrol descentants) with a language property to allow for localization that would be redundant as it only needs a single variable and all components should use the same language regardless eg you can't have a grid in english and the tree next to it in arabic it makes no sense at all its an all or nothing deal in my opinion.
So either introduce a new global variable eg localization : TLocalization; where you can have what ever properties you need or introduce it in an existing global variable eg screen, Application etc with application being the most obvious choice.
As for Delphi, D2007 that I have, it uses resource dlls and the system locale info to decide which dll to load when it starts up. after that the only way to change the language is to access the module linked list that any application keeps in memory to track which modules are loaded find the module record of the application (Module.instance = HInstance) and replace module.ResInstance with the newly loaded dll instance, cleaning up as required of course.
I do not think that has changed in newer version of delphi as well.
If it was up to me I would use something similar to a resource dll for 2 reasons
1) I do not want any of my end user to mess around with the translation with out my permission (sharing the translation tool to them) that would make support a nightmare. This can be achieved by encrypting the translation files as well.
2) localization is more than a simple string translation it has to support control positioning (I might have to group controls differently to be closer to official documents for example) and other properties as well eg. it would be silly to show an English interface on a right to left environment so this has to be changed to left to right as well regardless of the operating system's locale.
-
@Phil. Yes, at Run-Time. It isn't mirrored at Design-Time or it would be black then too. I've tried. :) Here's a screenshot of a form with a PageControl and some labels with themes ON.
-
I also want to see if I can find out how VB is doing Sorts and if it can be correct without regard to Language. It worked for Hebrew and English so...
VB doesn't sort or rather doesn't compare strings it uses the system CompareString (http://msdn.microsoft.com/en-us/library/windows/desktop/dd317759%28v=vs.85%29.aspx) which does a linguistic compare.
Yes, at Run-Time. It isn't mirrored at Design-Time or it would be black then too. I've tried. :) Here's a screenshot of a form with a PageControl and some labels with themes ON.
You do know that there is a example project for bidi in the examples\bidi directory right?
In it you can see how to change from left to right to right to left and vice versa and has a button to flip controls too, although I'm guessing that it does this by changing the controls position instead of relying in the bidi mode.
-
@Phil. Yes, at Run-Time. It isn't mirrored at Design-Time or it would be black then too. I've tried. :) Here's a screenshot of a form with a PageControl and some labels with themes ON.
Not sure what's going on there. It almost looks like the problem that a TCustomControl descendant can have if it leaves it's Color set to clDefault - in earlier versions of Laz, this was the same as clWindow, I believe, but it's now clBlack (or displays that way).
Might just be a coincidence...
Thanks.
-Phil
-
@Phil. No, I've done a huge amount of investigating. Any and all TCanvas become corrupted. If I add a few TEdits, as soon as I leave the first one, it's content is echoed to the Top-Right corner and is Mirrored. Then other very strange things start happening as you move from TWinControl to TWinControl. But the base Canvas stays black wherever it 'escapes' from the 'echo effect'. You would really have to see it to understand it. English written backwards isn't something I like to see on my forms. :)
-
@taazz.
...with a language property to allow for localization that would be redundant as it only needs a single variable and all components should use the same language regardless eg you can't have a grid in english and the tree next to it in arabic it makes no sense at all its an all or nothing deal in my opinion.
How then can I write a Hebrew/English dictionary? Or a Hebrew Form that requires English data as well such as 'Name, place of birth, date of birth...' for an International document? I have many Forms that are at least bilingual. 'All or nothing' means that I can't write these programs. Even your word processor likely support multilingual text. My real name is אבישי. Multilingual is simply a fact of life. Fortunately, Lazarus is flexible enough to allow me to do this. It just takes more work than it needs to.
-
@taazz.
...with a language property to allow for localization that would be redundant as it only needs a single variable and all components should use the same language regardless
+1 ; +1000000
How then can I write a Hebrew/English dictionary? Or a Hebrew Form that requires English data as well such as 'Name, place of birth, date of birth...' for an International document?
IIRC you said that you believe this to be a common situation. At least for apps targeting your language/country.
IMHO this is a highly specialized case, which can and should require the developer to add the support (e.g. hook OnEnter/Exit and change keyboard)
I do no want to start an endless amount of enumeration of existing software, that have or have it not. But allow me one. If indeed this was so common, then Excel (or OO/LibreOffice) would surely have support to set some columns to one and other columns to another language, after all a spreadsheet could easily be used to hold a name-list (bi-lingual). I am not aware of such an option.
For Sorting there also are events.
Only bidi-mode may be needed per control. Global mirroring of canvas makes sense per form.
-
Thanks Martin_fr. It is far more common that you seem to realize. The booklets that come with cameras, cars, bicycles... are almost always printed in multiple languages. Restaurants all over the world print menus in multiple languages. The deed to my land in Texas is in English and Spanish and was generated by a bilingual program. Many government documents are bilingual. If you Google the lyrics to a French song, many sites will have French lyrics and English translation side by side. Even my on-line banking is multilingual. Multilingualism is all around us every day. Monolingualism is like Henry Ford's 'You can have any color you want as long as it's black'. I could go on but there's no point.
Excel does very nicely mixing LTR and RTL. In Excel RtlExcel02.jpg, all I did was toggle Keyboard Language. Nothing at all special.
-
How then can I write a Hebrew/English dictionary? Or a Hebrew Form that requires English data as well such as 'Name, place of birth, date of birth...' for an International document? I have many Forms that are at least bilingual. 'All or nothing' means that I can't write these programs. Even your word processor likely support multilingual text. My real name is אבישי. Multilingual is simply a fact of life. Fortunately, Lazarus is flexible enough to allow me to do this. It just takes more work than it needs to.
I leave in a bilingual world my self (ee english is not my primary language) in all my years of developing I had to support at least 2 languages and some times 3 in the same document but I never had the need to support them on a screen layout. I consider it bad practice to have multilingual forms designs, everything should be in the user's native language.
The data that the application manages should be multilingual though, that means that the labels captions and everything else on a form (buttons, column headers etc) should be on the users native or preferred language. The data inside the controls Edit.Text, ListBox.Items etc should be in what ever language the user typed them in, of course if the requirements dictate for a multilingual document that should be taken care with the reporting tool.
That's my personal requirements on the design of multilingual applications. Any other way (eg bilingual forms) creates an inconsistency and negativity amongst users.
as always I have no idea of the specifics of your application but the little I have seen from the bidi demo I mentioned earlier everything seems to be in order with my understanding.
-
@taazz. I don't think we are that far apart on this issue. I use the Label of a TEdit or whatever as an indicator to the user so that they know what language they will be typing in (as default). If the Label is 'שם פרטי' they expect to be typing in Hebrew and don't start trying to type English. If the Label is 'First Name' they expect to be typing English. And I activate the correct Keyboard for the field in the OnEnter event so they aren't constantly having to toggle to it manually. If I see a Label that says 'First Name' but the Keyboard is Hebrew, that's just bad design.
-
This is about language switching now. This does not apply in the same grade to sorting or bidi painting.
Thanks Martin_fr. It is far more common that you seem to realize. The booklets that come with cameras, cars, bicycles... are almost always printed in multiple languages. Restaurants all over the world print menus in multiple languages.
Yes and any (utf8) text processing can deal with that. Still word doesn't (to the best of my knowledge) switch your keyboard language/layout.
The latter is my point.
In fact, if not auto translated, they may be written by different people. And then copy and pasted.
The switching of language in those cases is provided by the OS, not the app. The user can tell the OS via global key shtortcut. Works fine with todays lazarus. I do it all the time between English and German (if I need umlauts).
Sure there are cases, where application driven switching certainly is helpful. Writing a dictionary editor, with 2 fields, one per language. (Your gov dual name is the same)
But those cases are not the norm. They are exceptions.
How many big international Software companies provide that feature in their products (not talking development platforms, but finished products)? MS-Office? Afaik not. Open/LibreOffice? Anythink from Adobe? Or any other such company?
Maybe I am wrong. Maybe there is a big amount of such applications. Because, if this was such a common case, I would expect at least some of those big companies to get into that market and cash in on that need, wouldn't you think so?
Ok, Lazarus needs no financial incentive, to do a feature. But that was not the point. The point is to not get lost with highly specialized features and add them in the main code.
They can be provided as utility library, and then integrated/called by user code in the appropriate events.
The deed to my land in Texas is in English and Spanish and was generated by a bilingual program.
Despite that this program my be a specialized software as described, define bilingual?
The IDE is multilingual. You can change all the captions.
Libre office is too.
Even in Notepad I can type text in any language that I want. ( I did English, German, Japanese, and Arabic (I don't know what I typed in the latter 2, but I typed anyway).
Many government documents are bilingual. If you Google the lyrics to a French song, many sites will have French lyrics and English translation side by side. Even my on-line banking is multilingual. Multilingualism is all around us every day.
See above, all that works. (Well SynEdit has issues with Arabic. That is a bug)
Excel does very nicely mixing LTR and RTL. In Excel RtlExcel02.jpg, all I did was toggle Keyboard Language. Nothing at all special.
Exactly what I say. You toggle the language via the operating system. Excel does not have something, like a language per TEdit or per cell.
You can do that with todays Lazarus too.
Or as I said to start with: the *common* case is that language is controlled by the OS (including the user telling the OS)
-
If the Label is 'First Name' they expect to be typing English. And I activate the correct Keyboard for the field in the OnEnter event so they aren't constantly having to toggle to it manually. If I see a Label that says 'First Name' but the Keyboard is Hebrew, that's just bad design.
And I have never claimed that this was wrong in *your* application. It probably is a good thing in *your* app. And I also agree, that there are other apps where such behaviour exists and is desired.
What I say is those apps are specialized app.
You may work in an environment where they are common. But that does not make them common in general.
-
In my opinion, being able to properly sort a list isn't very *specialized*, or at least it shouldn't be. But in Lazarus it is.
The apps that you describe are primarily general purpose apps designed to fit a wide variety of users for an unknown task. I think the huge majority of Lazarus apps are designed to handle a very well defined task. In other words, specialized.
http://wiki.freepascal.org/Projects_using_Lazarus#Ancestroweb
I also don't expect every user to be especially computer literate. Many people don't know you can install other Keyboards or how to toggle through them. You can only toggle to a keyboard if it is installed. But an app can load any available keyboard without installing it. Telling a user they have to install xxx keyboard to use your software isn't good practice. And toggling through 5 or 6 languages on a routine basis isn't fun. Keyboard jockeys don't even know they're doing it, but we aren't all keyboard jockeys.
An International travel agency is a good example where bilingual software is a must. Some info is required to be in the language of the country they are in, and other info is required to be in English.
And there's also an accessibility issue involved. Some people need more help than others. Anything I can do to reduce the amount of user interaction required can be a blessing for some. That's an area I want to get more involved in. And yes, that can be very specialized.
Edit: Interesting information.
http://en.wikipedia.org/wiki/List_of_multilingual_countries_and_regions
-
As I said, you might want to look into how the Mono framework - the open source variant of the Microsoft CLR - handles this. On Windows, it should support RightToLeft etc as well... perhaps there's interesting hints in there....
What's he talking about are properties in WinForms forms. Mono's WinForms support is deprecated, I believe, and most certainly _not_ cross-platform.
http://msdn.microsoft.com/en-us/library/system.windows.forms.form.righttoleftlayout.aspx
I'm not sure what the state of MonoDevelop's form designer is for WinForms.
Thanks.
-Phil
Quick testing seems to indicate an existing .Net 2.0 Winforms application runs fine on Linux, except RTL does not seem to be supported... but I may be doing something wrong.
Language-specific string sorting etc may well work here, haven't looked.
Deprecated etc: even if it only supported Windows or is completely unsupported, that's not the point as long as it still is implemented. If so, we can still look at the code.
Regardless of the Mono winforms designer state, you can develop projects/solutions using SharpDevelop, probably Visual Studio, then read them and compile them with MonoDevelop.
Finally, Mono also supports the GTK backend, so that's another backend we can look into.
If you have better suggestions for Linux and/or Windows, please do post.
-
In my opinion, being able to properly sort a list isn't very *specialized*, or at least it shouldn't be.
In case that is a reply to me. I clearly stated I was talking about the original topic. Keyboard language toggled by application.
I also wrote that sorting is a different issue.
However. If sorting could/would follow the OS locale, or alternative could be set on TApplication, then that would cover many cases. There is also an OnCompare event. A unit with sort-helpers could be provided, and the app could call the correct one.
I also don't expect every user to be especially computer literate. Many people don't know you can install other Keyboards or how to toggle through them. You can only toggle to a keyboard if it is installed. But an app can load any available keyboard without installing it. Telling a user they have to install xxx keyboard to use your software isn't good practice. And toggling through 5 or 6 languages on a routine basis isn't fun. Keyboard jockeys don't even know they're doing it, but we aren't all keyboard jockeys.
I already answered this. An app can already do this.
I would have no problem if a unit LocalizationTools would contain a procedure (plain none OO procedure) SetKbdLang(c:TControl).
As for the rest (property on each control), I oppose and will keep opposing the idea (As in my personal opinion). I will not veto it, if other developers want to do it.
-
Seems we're all agreed that having application wide localization (including RTL support, locale-specific sorting) is desirable.
I'd suggest we start on that and allow application-specific enhancements in the design, as Martin indicated, which would allow per-control localizaton with some more effort on the programmer's part.
-
I volunteer this Numeric Sort :) I think it still needs some work though. If an item in the list is not numeric (i.e. 15A), it is listed at the Top (if SortAscending:= True), but this subset is not sorted.
I have tested on TListBox, TComboBox and TMemo.
I have SortAscending:= True in an Initialization section.
Example:
procedure TForm1.Button1Click(Sender: TObject);
begin
SortNumeric(ListBox1.Items);
SortAscending:= Not SortAscending;
end;
function DoNumSort(List: TStringList; Index1, Index2: Integer): Integer;
{ Works for Floats and Integers }
var
N1, N2: Double;
begin
N1:= StrToFloatDef(List[Index1],0);
N2:= StrToFloatDef(List[Index2],0);
if N1 < N2 then
result := -1
else if N1 > N2 then
result := 1
else
result := 0;
if not SortAscending then
Result:= -Result;
end;
procedure SortNumeric(Items: TStrings);
var
Alist: TStringList;
begin
Alist:= TStringList.Create;
with Items do begin
Alist.CommaText:= CommaText;
Alist.CustomSort(@DoNumSort);
CommaText:= Alist.commaText;
end;
FreeAndNil(Alist);
end;
-
Here are 3 more Sort routines, but someone that knows Portuguese needs to verify that it is correct.
function SortHebrew(List: TStringList; Index1, Index2: Integer): Integer;
{Hebrew}
begin
Result:= UTF8CompareStr(List[Index1],List[Index2]);
if not SortAscending then
Result:= -Result;
end;
function SortPortuguese(List: TStringList; Index1, Index2: Integer): Integer;
{Portuguese}
begin
Result:= WideCompareText(UTF8Decode(List[Index1]),UTF8Decode(List[Index2]));
if not SortAscending then
Result:= -Result;
end;
procedure SortHebGrid(Sender: Tobject; Acol, Arow, Bcol, Brow: Integer; Var Result: Integer);
begin
if Sender is TStringGrid then
with TStringGrid(Sender) do begin
Result:= UTF8CompareStr(TStringGrid(Sender).Cells[Acol,Arow],TStringGrid(Sender).Cells[Bcol,Brow]);
if SortOrder = soDescending then
result := -result;
End;
End;
-
You want to hardcode one per language?
And why oh why does
- UTF8CompareStr do Hebrew
- WideCompareText do Portuguese?
If you ask me (but I do not maintain this, so better try to get feedback from maintainers / mail list)
1) What can the OS already do?
2) For out of OS sorting:
One sorting procedure, that can be given a collation as argument. The collation needs to be stored as some data structure somewhere.
But just my 2 cent.
-
The idea was only to give a starting point. When it is known which Sorts are in common, I would assume that they would be grouped in some fashion, not individual. But until that is known, I see no way to group them or even know how many there will need to be.
I know that UTF8CompareStr works for Hebrew, but I was told that it does not work for Portuguese. The routine I gave is the one that was I was told does work. That's why I said it needs to be verified.
My collation routine is based on Language and since that seems to be off the table, I haven't posted it. And I will be the first to admit that my solution is half baked. Without the knowledge of what Sorts are needed, I simply gave it my best shot.
Bottom line, you have to start somewhere and refine it when new information becomes available.
-
This is my very 'beginner' first try and a collation process. I am in no way advocating this method. It was only an attempt to understand the issue. I have made so many recent changes that I am not even sure that it works at the moment. The const values have no real meaning and a better plan should have been used, but it was enough for testing.
const
EnglishSort = 0;
HebrewSort = 1;
PortugueseSort = 2;
NumericSort = 3;
{ This is the User Sort main routine }
{ Example Call: SortStringList(Memo1.Lines, HebrewSort); }
{ Example Call: SortStringList(ListBox1.Items, HebrewSort); }
{ Example Call: SortStringList(ComboBox1.Items, HebrewSort); }
function SortStringList(AStringList: TStrings; SortStyle: Integer): Integer;
var
SortList: TStringList;
begin
SortList:= TStringList.Create;
SortList.CaseSensitive:= True;
SortList.Assign(AStringList);
case SortStyle of
EnglishSort: SortList.Sort;
HebrewSort: SortList.CustomSort(@SortHebrew);
PortugueseSort: SortList.CustomSort(@SortPortuguese);
NumericSort: SortList.CustomSort(@DoNumSort);
end;
AStringList.Assign(SortList);
FreeAndNil(SortList);
end;
-
Seems there's some movement on sorting based on various collation:
http://bugs.freepascal.org/view.php?id=22909#c65896
of course, only in trunk and it probably hasn't been committed yet (haven't checked) - would be nice if there were a way to set collation as well...
Or maybe I misunderstand - haven't looked at the actual patch, but it sounds interesting.
-
Since I'm visiting in the US, I had a chance to take a quick look at the Latest Delphi. I ran some of the same sort tests that I did with Lazarus and Delphi doesn't have the nightmarish sorting problems. I'm not sure how it does it but it was successful in sorting a Hebrew list with NO coding in TListBox.Sort and TComboBox.Sort. If I have another chance I will do more tests and try to look at the code to see what it is doing.
-
The subject of Sorting a TStringList came up in BugTracker again. See issue# 0025378 - 'The Sort procedure in TStringList doesn't work correctly.'
A link was provided (https://www.gnu.org/software/coreutils/faq/#Sort-does-not-sort-in-normal-order_0021) that explains how TStringList.Sort is supposed to work.
If I read it correctly, it uses the System.Locale and not the Application.Locale. That make absolutely no sense. If my System.Locale is the US and I need to sort a list of French strings, I have to change my System.Locale??? (Yes I know I can use CustomSort but I would have to build an elaborate system and know which sort methods to use for an unknowable language).
Also it doesn't seem to work that way anyway. My System.Locale is Israel and TStringList.Sort completely scrambles a list of Hebrew strings. I checked it in Delphi and TStringList.Sort had no problem getting the sort order right.