home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 2
General
Globalization string management tool
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Albert" data-source="post: 710576" data-attributes="member: 67886"><p><strong>AW: Re: Globalization string management tool</strong></p><p></p><p></p><p>"it makes a lot of sense to push the strings to where they should be" -> What exactly do you mean by that? During translation time or during runtime?</p><p>At translation time, I don't want to change the original plugins (which are being localized). Why? Because our community members will do translations in their favorite language and send us the localization as a new plugin. That's why I think localizations will most probably be in separate plugins. And off course, the translator doesn't want to create N plugins; he will probably create ONE single plugin where his translation is contained.</p><p></p><p></p><p>That assumption is absolutely correct. Every plugin MUST provide english strings for each localized resource, so you can see the set of english strings as the master set - that set which consists of 100% of the strings which need to be localized. If a plugin dev puts another strings file into his plugin, maybe an english strings file and a french one, and if they are different, the english one counts.</p><p></p><p></p><p></p><p>My idea is something like that:</p><p>Lets say, we identify a standard way how translations are done. Maybe the way I explained above: Normal plugins will contain english strings and then there are additional language plugins containing languages for multiple other plugins.</p><p></p><p>If the string manager tool is started, it sees multiple plugins, multiple languages and multiple dependencies. The tool has the job to support the translator with his work, so it would be good if it could give as much help as possible. But, the problem is, because our system is so flexible, the tool cannot really decide which situation is ok and which is not ok. And here comes the "standard way" into play; The tool can compare the situation it finds in the plugins and strings files with the standard way how things should be done. Then it can give the user hints in which aspects the current situation differs from the way how it should be done.</p><p></p><p>The user can also do it completely different, but then, the tool cannot help him so much as if he would do it as expected.</p><p></p><p>Would that be a solution?</p></blockquote><p></p>
[QUOTE="Albert, post: 710576, member: 67886"] [b]AW: Re: Globalization string management tool[/b] "it makes a lot of sense to push the strings to where they should be" -> What exactly do you mean by that? During translation time or during runtime? At translation time, I don't want to change the original plugins (which are being localized). Why? Because our community members will do translations in their favorite language and send us the localization as a new plugin. That's why I think localizations will most probably be in separate plugins. And off course, the translator doesn't want to create N plugins; he will probably create ONE single plugin where his translation is contained. That assumption is absolutely correct. Every plugin MUST provide english strings for each localized resource, so you can see the set of english strings as the master set - that set which consists of 100% of the strings which need to be localized. If a plugin dev puts another strings file into his plugin, maybe an english strings file and a french one, and if they are different, the english one counts. My idea is something like that: Lets say, we identify a standard way how translations are done. Maybe the way I explained above: Normal plugins will contain english strings and then there are additional language plugins containing languages for multiple other plugins. If the string manager tool is started, it sees multiple plugins, multiple languages and multiple dependencies. The tool has the job to support the translator with his work, so it would be good if it could give as much help as possible. But, the problem is, because our system is so flexible, the tool cannot really decide which situation is ok and which is not ok. And here comes the "standard way" into play; The tool can compare the situation it finds in the plugins and strings files with the standard way how things should be done. Then it can give the user hints in which aspects the current situation differs from the way how it should be done. The user can also do it completely different, but then, the tool cannot help him so much as if he would do it as expected. Would that be a solution? [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 2
General
Globalization string management tool
Contact us
RSS
Top
Bottom
