A localizable version of each of the Affinity programs such that the localization of the menus is using an external localization file

[William Overington]

A suggestion for there being a localizable version of each of the Affinity programs such that the localization of the menus is using an external localization file.

This would be a substantial task to implement, but could potentially have substantial benefits.

In an Affinity program there are menus, for example with words in English.

My suggestion is that each string literal, such as File is replaced in the localizable version of that Affinity program by an element of a string variable array.

It is important that the string array can handle Unicode characters so as to provide for the greatest possible number of localized versions being possible, please ensure that 8-bit characters are NOT used. Please do NOT use UTF-8, please use UTF-16.

Bearing in mind that I have not programmed for many years, this may not be expressed in the source code of the programming language that is being used  for Affinity programs, but hopefully my meaning will get through to your programmers.

Suppose that the string literal "File" is replaced by an element of a string array, say, afmenu[1] and that afmenu[1] has a default value of "File".

At start up the program looks for a UTF-16 text file aflist.dat and, if it finds such a file, populates the afmenu array as much as it can from the aflist.dat file. Thus the afmenu array has text in each of its elements, none, some, or all of the afmenu items having text in English and the rest of the afmenu items having the text in the language of the particular aflist.dat file that was used. So for example, there could be an aflist.dat file in Estonian, an aflist.dat file in Welsh, and so on, and the end user could choose which aflist.dat file to use. There are commercial translation facilities that could translate and localize a copy of the English aflist.dat file into another language.

The aflist.dat file could use the same format as the sentence.dat file specified in a document available from my webspace.

http://www.users.globalnet.co.uk/~ngo/localizable_sentences_research.htm

The file is as follows.

http://www.users.globalnet.co.uk/~ngo/The_Format_of_the_sentence_dot_dat_files_for_use_in_Research_on_Communication_through_the_Language_Barrier_using_encoded_Localizable_Sentences.pdf

There are issues that a font with glyphs for the characters used in the language into which localization is made will be needed and there will be issues for the rendering of some languages.

This would be a quite large project to implement but the potential benefits of implementation could also be large too.

William J. G. Overington

Tuesday 16 April 2024

 

Edited April 17 by Patrick Connor
Do NOT call staff into threads they are not already participating in

[William Overington]

@R C-R The purpose is so that versions of Affinity software programs could become available with menus in any one of many languages. Once the localizable version is set up, producing a version in another language would be by getting a copy of the English version aflist.dat file translated and localized into that other language. So there could be a version of each Affinity program in each of hundreds of languages. With a default menu item in English if a translation for a particular menu term is not available.

William

 

 

[R C-R]

I know the purpose. That is not why I added the Sad reaction. I leave it to you to figure out why I did that.

[Pšenda]

12 hours ago, R C-R said:

I leave it to you to figure out why I did that.

Maybe because it's been requested many times already, and Serif has commented on it many times. If I remember correctly, Serif bears full responsibility for its applications, and therefore also for the correctness of the translations. It is not Open source, Shareware or Freeware for users to finish at home.

P.S. Translation using external tables is suitable at most for menu items, where the variable/different length of words with the same meaning does not matter so much, but it is not suitable for UI, where it can cause complete disintegration and illegibility of forms and panels.

Edited April 17 by Pšenda

[William Overington]

The aflist.dat file could be encrypted such that it would not load if the encryption of a passcode were not correct. So Affinity could have provenance that only an official Affinity aflist.dat file would work.

What Serif may have said in the past is gone. Canva are the new owners with Affinity now having more money to invest in moving forward and if they made this idea work they could perhaps get good publicity for Affinity products as being go ahead and futuristic.

Look to the future, not be shackled by the past.

William

 

[William Overington]

10 hours ago, Pšenda said:

Maybe because it's been requested many times already, and Serif has commented on it many times. If I remember correctly, Serif bears full responsibility for its applications, and therefore also for the correctness of the translations. It is not Open source, Shareware or Freeware for users to do at home.

P.S. Translation using external tables is suitable at most for menu items, where the variable/different length of words with the same meaning does not matter so much, but it is not suitable for UI, where it can cause complete disintegration and illegibility of forms and panels.

As regards the User Interface, whether my suggestion is suitable will depend upon how it is done.

A paragraph of text over several lines can be divided into several single lines. Setting up of the localization file always has a human input, this is not a machine translation scenario.

William

 

[William Overington]

10 hours ago, Pšenda said:

Maybe because it's been requested many times already, and Serif has commented on it many times.

Under the new ownership Pledge 4 has been made, so a new era may have different thinking.

William

 

[R C-R]

4 hours ago, William Overington said:

As regards the User Interface, whether my suggestion is suitable will depend upon how it is done.

A paragraph of text over several lines can be divided into several single lines. Setting up of the localization file always has a human input, this is not a machine translation scenario.

This has nothing to do with paragraphs, just with the space available in the UI for words & phrases that are of different lengths in different languages (not to mention different writing directions, which is a much more difficult problem to address).

This has been discussed at length & in great detail in the forums for years, so if you had just done a little research first, you would have realized your suggestion has added nothing of any practical value to this long running request.

BTW, in this respect, for what should be obvious reasons there is no "new era" so your repeating that fatuous catch phrase here is just as meaningless as it was in the other topic.

[William Overington]

1 hour ago, R C-R said:

BTW, in this respect, for what should be obvious reasons there is no "new era" so your repeating that fatuous catch phrase here is just as meaningless as it was in the other topic.

I am always wary when someone purports obvious reasons without stating what are any of those purportedly obvious reasons that are purported to exist.

Pledge 4 has been issued as a result of discussions involving Canva, so it is a new era for Affinity as Canva were not, as far as I am aware, previously involved in the management of Affinity activity.

William

 

[R C-R]

49 minutes ago, William Overington said:

Pledge 4 has been issued as a result of discussions involving Canva, so it is a new era for Affinity as Canva were not, as far as I am aware, previously involved in the management of Affinity activity.

Pledge 4 has nothing to do with the fact that your suggestion is nothing more than a trivialization of one that has been discussed many times in the past, including the need to make substantial changes in how the UI is implemented to get it to work.

Besides, it should be obvious that Pledge 4 is not significantly different from what Serif was doing before Canva bought it as far as considering user feedback & ideas when deciding what features to implement. But since you posted this to the existing Feedback & Suggestions forum, please consider what it says about searching first before starting a new topic.

[William Overington]

6 hours ago, R C-R said:

Pledge 4 has nothing to do with the fact that your suggestion is nothing more than a trivialization of one that has been discussed many times in the past, including the need to make substantial changes in how the UI is implemented to get it to work.

Well, then substantial changes could be made to a copy of the source code to get what I have suggested to work, without in any way altering the basic versions at all. I have not suggested that it could all be done in half an hour.

With innovation I have found that one needs to be willing to try something even if it might appear pointless to do, because it can often unexpectedly lead to something good. Many people try to extrapolate from the known into the unknown on an opinion without actually testing whether their assumptions are correct.

Pledge 4 is a new beginning. It is not a good idea to grumble away that wonderful opportunity.

6 hours ago, R C-R said:

Besides, it should be obvious that Pledge 4 is not significantly different from what Serif was doing before Canva bought it as far as considering user feedback & ideas when deciding what features to implement. But since you posted this to the existing Feedback & Suggestions forum, please consider what it says about searching first before starting a new topic.

Well, I don't know whether Pledge 4 is significantly different from what happened previously. I am hoping that [edited] will say how in the new Canva era ideas will be assessed and whether feedback will be provided by private email to those who have suggested ideas. It does not need to be the old no comment secretive assessment process from times gone by, Affinity could seize the great opportunity of Pledge 4 to go forward splendidly. I hope that the opportunity is not grumbled away.

William

 

Edited April 17 by William Overington
I did not know at the time that I posted that listing a member of staff is not permitted

[R C-R]

4 minutes ago, William Overington said:

Well, I don't know whether Pledge 4 is significantly different from what happened previously.

It isn't. The "guided by" verbiage just means the developers will consider user suggestions, which they have always done. The idea that they would reply by private mail to suggestions is ludicrous since it would mean that each & every person who makes a suggestion would have to be emailed (or PM'ed, which I think is what you really mean) individually, creating a huge amount of work with no real benefit to anybody.

6 minutes ago, William Overington said:

Well, then substantial changes could be made to a copy of the source code to get what I have suggested to work, without in any way altering the basic versions at all.

Nonsense. Substantial changes of necessity mean changing the basic code itself. It doesn't matter if they start with a copy of the source code to do this or not. Either way, the changes have to be incorporated into the apps.

[Alfred]

1 minute ago, R C-R said:

Substantial changes of necessity mean changing the basic code itself. It doesn't matter if they start with a copy of the source code to do this or not.

Which would in turn necessitate extensive testing to make sure that those changes don’t break anything. All in all, a huge investment of time and effort (and therefore money).

[William Overington]

58 minutes ago, R C-R said:

It isn't.

Well, as I wrote before, I don't know whether Pledge 4 is significantly different from what happened previously or not.

As far as I am aware, there is no information published to customers pursuant to Pledge 4 as to what is the situation over assessment of ideas and feedback about suggested ideas now that Affinity is owned by Canva.

I am hoping that [edited] will explain what assessment process will be used.

The purchase of Affinity by Canva is a big event, so maybe the situation will change, or maybe the idea is to keep everything as it was lest changing anything spoils what has been bought.

William

 

Edited April 17 by William Overington
I did not know at the time that I posted that listing a member of staff is not permitted

[William Overington]

28 minutes ago, Alfred said:

Which would in turn necessitate extensive testing to make sure that those changes don’t break anything. All in all, a huge investment of time and effort (and therefore money).

Well yes, but ideas are being sought and I have suggested one. If my idea could be got working there could be versions of Affinity programs in hundreds of languages. The incremental cost of each additional language being relatively low.

William

 

[William Overington]

So perhaps the way forward would be for one or two people at Affinity to try to start with a copy of the source code of Affinity Designer and try to produce a version - a sort of software maquette - that will do the localization effect on just three menu items, so that the idea can be seen in action.

The resulting demonstration could be inspiring.

Is that possible please?

William

 

[thomaso]

On 4/16/2024 at 11:34 PM, William Overington said:

My suggestion is that each string literal, such as File is replaced in the localizable version of that Affinity program by an element of a string variable array.

It is important that the string array can handle Unicode characters so as to provide for the greatest possible number of localized versions being possible, please ensure that 8-bit characters are NOT used. Please do NOT use UTF-8, please use UTF-16.

How it currently works: "Strings" + "Unicode UTF-16":

On 4/17/2024 at 12:21 AM, William Overington said:

So there could be a version of each Affinity program in each of hundreds of languages.

For what purpose / advantage?  Not only the interface layout requires adjustments to make "hundreds of languages" fit without cropping or other issues, also the Help and all tutorials, static or video, various websites (incl. store and forum) would need an according translation to make sense of "hundreds of languages" for the app interface.

Apart from the required effort to complete your vague and superficial "idea" its sense gets reduced if you consider who could in fact benefit from this work. It is not the users of "hundreds of languages" who might not even be able to purchase soft- or hardware but this would also require understanding of all the localised terms: For example, while you can translate "Leading Override" or "Curve Adjustment" into any language, it might not have the meaning used in DTP.

So, without additional education of users + translation of related documents, an app interface in "hundreds of languages" isn't useful but simply redundant – while with education also one of the existing interface languages got learned quite likely and thus an interface in "hundreds of languages" is redundant, too.

(Not to mention the "idea" that automatic translation will become carried out by AI in more and more areas, without a need for extra manpower or feature requests)

[JGD]

16 hours ago, thomaso said:

Apart from the required effort to complete your vague and superficial "idea" its sense gets reduced if you consider who could in fact benefit from this work. It is not the users of "hundreds of languages" who might not even be able to purchase soft- or hardware but this would also require understanding of all the localised terms: For example, while you can translate "Leading Override" or "Curve Adjustment" into any language, it might not have the meaning used in DTP.

So, without additional education of users + translation of related documents, an app interface in "hundreds of languages" isn't useful but simply redundant – while with education also one of the existing interface languages got learned quite likely and thus an interface in "hundreds of languages" is redundant, too.

(Not to mention the "idea" that automatic translation will become carried out by AI in more and more areas, without a need for extra manpower or feature requests)

Bingo! Even across different countries (hence me mentioning pt-PT vs. pt-BR) technical jargon can vary, and you'd need at least one expert consultant and one translator (or, ideally, someone who can do both) for each language…

Regarding automatic translation, I've seen such stupidity on apps distributed by large companies that I suspect many didn't get the memo yet, but I hope they will after getting enough user feedback. Just yesterday I fired a string of five or six support tickets to Leroy Merlin (it's like a big French hardware store chain with locations across all of Europe), because their Enki home automation control app is full of bugs, and one of the last ones, pertaining to their deplorable translation efforts (complete with entire paragraphs in English on the very support ticket submission webform), was focused on this pearl: the usage of the Portuguese word “Perto”, which means “close” as in “nearby”, for the “Close” button, instead of the correct and standard verb “Fechar” in the infinitive. Interestingly, the app was, I suspect, done by French coders, but they must've standardised in English, because “Fermer”, the unambiguous conjugation of the same verb in French, would never translate into “Perto”… But that just goes to show how you just can't rely exclusive in “AI” (it's not true AGI, it's just LLMs, and LLMs are just mass plagiarising machines with some PR and advertising lipstick on them).

[Leigh]

Pruned and locked. William has provided his feature request but as others have pointed out, it's been requested before. No need for another thread on this.