Add 'Language' property to Controls with Text?

[Martin_fr]

@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.

[Avishai]

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.

[taazz]

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.

[Avishai]

@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.

[Martin_fr]

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)

[Martin_fr]

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.

[Avishai]

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

[BigChimp]

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.

[Martin_fr]

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.

[BigChimp]

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.

[Avishai]

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;

Code: [Select]

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;


[Avishai]

Here are 3 more Sort routines, but someone that knows Portuguese needs to verify that it is correct.

Code: [Select]

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;
 

[Martin_fr]

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.

[Avishai]

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.

[Avishai]

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.

Code: [Select]

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;