Forum

Hello!
I intend to develop the program based on Russian version of Subsystem Library and in the future to translate it into English and Chinese.
The most difficult part of the translation, I expect, is the Subsystem Library.

If I write the program as a multilanguage program and merge it with Russian or English Subsystem Library on late stage of development, my unmerged program will be inoperable because I have to include standard Subsystem Library's calls without its modules.

If I merge my program with SL on early stage of the development, I shall have to translate SL.

Parallel development object by object is possible but it is slow and requires more accuracy.

What the order of the development could 1C recommend?

Hello, Serge Titov.

If you plan to use your application on English- and Chinese-speaking markets, we recommend you using English version of 1C:Subsystems Library and create your application with English script variant.
You can use the 1C:Subsystems Library translation dictionary built into 1C:Translator and this application itself (project of the 1C application interface translation type) to restore most of Russian interface of 1C:Subsystems Library or extract it from 1C:Small Business or 1C:Translator where Russian interface exist.

Timofey, I would suggest to publish SL to Git and let developers all around the world make changes to create international version of SL. We grabbed some code from SL to our project years ago and when tried to update to more recent version it was almost impossible. So we have two options:
1. stuck with outdated version, but translated
2. translate it every time new version of SL released
We have chosen 1 option.

Hello, Alexey!

Would you please explain how Git will help in updating SL?

I also can tell you that I have embedded SL version 2.0 into 1C:Translator and when SL 2.2 was published, I have updated it in a reasonable period of time.

If you have any questions regarding 1C:SL, please ask in this forum, we are always happy to assist you.

Making SL international is not just translating messages. We had to redesign contact information beacuase it is quite different compared con Russian or US-optimized version. So we could contribute our code and experience to SL and make it more suitable for other countries. Also it is great to view and have been changed and be able to review last commits to decide what should be translated / reworked.
Another important thing is to provide methodological information to partners and encourage them to use SL in their products.

Alexey,

It's very good idea.
How I know 8.4 supports github work logic.
As in Turkey we working from 2007 we can support on turkish version.
We transitted our solutions from ordinary application to managed. Platform updates very quickly. Some changes require much changes in configuration. So even if configuration is not little, becomes much more difficulties to update configurations.

It will be perfect idea to update SL from github.

Thank you for the idea, we will discuss it.

Meanwhile, who is ready to participate this project and provide new functionality?

We are ready to participate. We could contribute in address form for Latin America, translation and, of course, bug fixes.