Translation dutch

[JanH]

Normally all the text in programs are stored in a file. I asumed that thuis is also within affinity. May be someone van make translations for you. Lots of the dutch Ushers are very pleased if affinity photo is translated in our native language. How do we do this.

[dutchshader]

Hallo Jan,

Die vraag is al vaker gesteld en het antwoord van serif is dat ze dat bestand niet vrij geven.

Ook is er nog geen Nederlandse versie in de planning.

[R C-R]

6 hours ago, JanH said:

Normally all the text in programs are stored in a file.

I don't know how Windows does it but for Macs, it is not that simple. There are multiple "strings" files that contain word & phrase substitution pairs, each set for a different supported language, & provisions to use the appropriate ones based on either the system-wide or in-app language choice.

The help system also includes multiple sets of files for different supported languages.

[v_kyr]

7 hours ago, R C-R said:

I don't know how Windows does it...

• Globalizing and localizing applications

It's pretty much a similar procedure there. - Beside that UI elements have also to be sized and adapted accordingly for different localized languages.

[R C-R]

2 minutes ago, v_kyr said:

It's pretty much a similar procedure there. - Beside that UI elements have also to be sized and adapted accordingly for different localized languages.

Thanks for the info & the URL. From a quick browse through some of the linked pages & what (little!) I know about the Mac side of it, it looks like both macOS & Windows provide basically the same kinds of language & cultural localization services. The details differ but both rely on multiple file resources organized in complex hierarchies & various mechanisms to make it all work.

[v_kyr]

Yes it's mostly everywhere like that for language & cultural localization services, all use a similar approach in keeping localized UI based text strings in separate resource files (instead inbetween/inside the source code itself) so they can be easier handled for this purpose. - Though in practice, it's also a lot of work to set and check up, seeing/testing if it always behaves everywhere (for every supported languange) in a well working manner. All in all it's a time consuming task and something coders usually don't like to do that much (not her favorite pastime), if they could do instead more real coding.

[JanH]

On 12/2/2018 at 5:13 AM, R C-R said:

I don't know how Windows does it but for Macs, it is not that simple. There are multiple "strings" files that contain word & phrase substitution pairs, each set for a different supported language, & provisions to use the appropriate ones based on either the system-wide or in-app language choice.

The help system also includes multiple sets of files for different supported languages.

In Windows, if you use Visual Studio, the best approach is to set all the text in a resource file. Just translate the strings in that file will do.

[R C-R]

48 minutes ago, JanH said:

In Windows, if you use Visual Studio, the best approach is to set all the text in a resource file. Just translate the strings in that file will do.

If you include all the help file resources & everything else that is needed for language & cultural localization support, that would be a very massive file! Somehow, I can't see that as a very good way to optimize the UI for the responsiveness or memory efficiency characteristic of the Affinity apps, but what do I know?

[JanH]

On 12/2/2018 at 2:57 PM, v_kyr said:

Yes it's mostly everywhere like that for language & cultural localization services, all use a similar approach in keeping localized UI based text strings in separate resource files (instead inbetween/inside the source code itself) so they can be easier handled for this purpose. - Though in practice, it's also a lot of work to set and check up, seeing/testing if it always behaves everywhere (for every supported languange) in a well working manner. All in all it's a time consuming task and something coders usually don't like to do that much (not her favorite pastime), if they could do instead more real coding.

Never said it is a piece of cake. But don't use developpers for such a job. If translated to a user native language, many more copies will be sold in these countries. So the costs of a translator and tester for that language are then peanuts. And the beta versions will be tested by users.

[JanH]

On 12/2/2018 at 12:40 PM, v_kyr said:

• Globalizing and localizing applications

It's pretty much a similar procedure there. - Beside that UI elements have also to be sized and adapted accordingly for different localized languages.

agree. There are already some 8 to 10 languages, so there won't be many places, where elements must be sized.

[JanH]

On 12/9/2018 at 5:44 PM, R C-R said:

If you include all the help file resources & everything else that is needed for language & cultural localization support, that would be a very massive file! Somehow, I can't see that as a very good way to optimize the UI for the responsiveness or memory efficiency characteristic of the Affinity apps, but what do I know?

Help files are all on line, so I couldn't see their sizes. Resource files are about 4 to 5 MB.

[R C-R]

12 minutes ago, JanH said:

Help files are all on line, so I couldn't see their sizes. Resource files are about 4 to 5 MB.

I don't know about the Windows versions but in the Mac ones the help files are built into each app, as "help bundles." They are based on HTML, like web pages, but are accessed locally through the Mac help system rather than remotely through a browser app. For Designer, the bundle is about 75 MB, around 20 MB of which are in 200 or so shared resource files used to some extent in each of the localizations. The 'lproj' (Localized Project) folders contain the language & cultural specific HTML indexes, style sheets, strings files, images, help page category folders, & so on. These lproj folders are not very large, typically only 4-5 MB each, but often contain several hundred small files that provide the specifics of each localization.

There are also provisions built into the Mac help system to update the files as needed from remote servers, but I don't know much about that, other than everything has to be tagged or linked in some way for that to work.

Anyway, the gist of it is this involves much more work than just translating a few text files; it is much more like building an entire web site that includes thousands of files, links, & the code that binds it all together.

[walt.farrell]

The Help files on Windows are also local, but they are HTML files.

[R C-R]

4 minutes ago, walt.farrell said:

The Help files on Windows are also local, but they are HTML files.

Do they have a similar structure like in the Mac ones where there are thousands of different files?

[walt.farrell]

36 minutes ago, R C-R said:

Do they have a similar structure like in the Mac ones where there are thousands of different files?

Yes. Lots of directories with lots of files in each.

[JanH]

4 hours ago, R C-R said:

I don't know about the Windows versions but in the Mac ones the help files are built into each app, as "help bundles." They are based on HTML, like web pages, but are accessed locally through the Mac help system rather than remotely through a browser app. For Designer, the bundle is about 75 MB, around 20 MB of which are in 200 or so shared resource files used to some extent in each of the localizations. The 'lproj' (Localized Project) folders contain the language & cultural specific HTML indexes, style sheets, strings files, images, help page category folders, & so on. These lproj folders are not very large, typically only 4-5 MB each, but often contain several hundred small files that provide the specifics of each localization.

There are also provisions built into the Mac help system to update the files as needed from remote servers, but I don't know much about that, other than everything has to be tagged or linked in some way for that to work.

Anyway, the gist of it is this involves much more work than just translating a few text files; it is much more like building an entire web site that includes thousands of files, links, & the code that binds it all together.

 

1 hour ago, walt.farrell said:

Yes. Lots of directories with lots of files in each.

This is a browser that is build in and work like an external browser. Where files are kept is not so important for a browser. The best practise is to keep them on a website.

 

[walt.farrell]

1 minute ago, JanH said:

The best practise is to keep them on a website.

That depends.

Serif has the Affinity Help files on a website, for example. But:

• Are they for Mac or Windows?
• Are they for 1.6.5 or 1.7?
• If things change between driver levels of 1.6.5, will they be for the older version or the newer version?

If they are kept with the program, on your machine, they can be made applicable to exactly your version and OS.

[JanH]

16 minutes ago, walt.farrell said:

That depends.

Serif has the Affinity Help files on a website, for example. But:

• Are they for Mac or Windows?
• Are they for 1.6.5 or 1.7?
• If things change between driver levels of 1.6.5, will they be for the older version or the newer version?

If they are kept with the program, on your machine, they can be made applicable to exactly your version and OS.

You can have multiple website versions if necessary for every language and  each version of the software. In the app just address the right file. Serif can ask us dutch to help them with the translation. I am retired and have some time left. But it is better that they do it. Keep in control of your own software.

[R C-R]

3 hours ago, JanH said:

The best practise is to keep them on a website.

It definitely would not be the best practice in any of these real world situations:

1. A user is working somewhere with no available access to the internet.
2. A user has a slow or intermittent connection
3. A user has a metered plan that either throttles download speeds after a cap is reached or charges more when it is exceeded

As it is, at home my service is very fast (typically >300 Mbps for downloads), yet it still can take 30 seconds or more just for a help file update to download, & that typically involves downloading only a small number of files. Imagine what it would be like if each help topic had to be downloaded each time it was accessed & the connection was slow or iffy.

3 hours ago, JanH said:

You can have multiple website versions if necessary for every language and  each version of the software. In the app just address the right file.

There is no one "right" file. There are hundreds of them for each localization, plus hundreds more for the ones shared by all localizations. Neither are they all text files.