Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1

[Olaf Siejka]

>  
>
>  - Declarative module localizations : Now module localizations are created
>  in
>  a declarative way which makes trivial tasks like listing non existent or
>  outdated language localizations in real time  for example :
>
>  http://www.codexchange.net/rosdoc/localizations.htm
>
>  Let me know your opinions and suggestions as I would like to start
>  finishing
>  some of this features and merge all/part of my changes back to trunk
>  
I find this part extremely important. It would allow real-time tracking of
translation progress/status (if i understood it correctly) which would
greatly help maintain all the growing ROS localizations and help all ROS
translating teams. Such webpage, as you presented here, should be created on
ROS website as soon as it would be possible.

[Marc Piulachs]

Hi Olaf,

 

You understood it correctly; the idea is graphically show an up-to-date
localization status report. Not only which modules are translated to each
language, but also if any of the localizations is "dirty" (meaning that
exists but contains new unlocalized strings). It will make the task of
maintaining updated translations easier.

 

/marc

 

  _____  

From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
Behalf Of Olaf Siejka
Sent: Sunday, November 04, 2007 11:11 PM
To: ros-dev(a)reactos.org
Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1

 


- Declarative module localizations : Now module localizations are created in
a declarative way which makes trivial tasks like listing non existent or
outdated language localizations in real time  for example :

http://www.codexchange.net/rosdoc/localizations.htm

Let me know your opinions and suggestions as I would like to start finishing
some of this features and merge all/part of my changes back to trunk 


I find this part extremely important. It would allow real-time tracking of
translation progress/status (if i understood it correctly) which would
greatly help maintain all the growing ROS localizations and help all ROS
translating teams. Such webpage, as you presented here, should be created on
ROS website as soon as it would be possible.

[Colin Finck]

The open question would be: What happens with the already planned/prepared
online translation service?
It also had a plan to improve the whole translation process, but as far as I
know it differs much from your solution.
 
Klemens, Magnus, any comments on this?
 
Regards,
 
Colin
 



  _____  

From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
Behalf Of Marc Piulachs
Sent: Monday, November 05, 2007 2:26 PM
To: 'ReactOS Development List'
Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1



Hi Olaf,

 

You understood it correctly; the idea is graphically show an up-to-date
localization status report. Not only which modules are translated to each
language, but also if any of the localizations is "dirty" (meaning that
exists but contains new unlocalized strings). It will make the task of
maintaining updated translations easier.

 

/marc

 


  _____  


From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
Behalf Of Olaf Siejka
Sent: Sunday, November 04, 2007 11:11 PM
To: ros-dev(a)reactos.org
Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1

 


- Declarative module localizations : Now module localizations are created in
a declarative way which makes trivial tasks like listing non existent or
outdated language localizations in real time  for example :

http://www.codexchange.net/rosdoc/localizations.htm

Let me know your opinions and suggestions as I would like to start finishing
some of this features and merge all/part of my changes back to trunk 


I find this part extremely important. It would allow real-time tracking of
translation progress/status (if i understood it correctly) which would
greatly help maintain all the growing ROS localizations and help all ROS
translating teams. Such webpage, as you presented here, should be created on
ROS website as soon as it would be possible.

[Marc Piulachs]

Hi Colin,

 

I don't have an answer to your question but can make two considerations:

 

-          Is the online service application finished? Or even seriously
planned? Will be available in the following 2 , 4 or 6 months? I think the
question is: If current localization process can be *really* improved should
we do nothing till the online service is ready?

-          If my proposed solutions is adopted just as a intermediate
solution while we wait for the online service to be completed all the
efforts made will be worth it as we can generate a xml report from it and
import them to the online service database with ease.

 

/marc

 

  _____  

From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
Behalf Of Colin Finck
Sent: Monday, November 05, 2007 3:44 PM
To: 'ReactOS Development List'
Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1

 

The open question would be: What happens with the already planned/prepared
online translation service?

It also had a plan to improve the whole translation process, but as far as I
know it differs much from your solution.

 

Klemens, Magnus, any comments on this?

 

Regards,

 

Colin

 

 


  _____  


From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
Behalf Of Marc Piulachs
Sent: Monday, November 05, 2007 2:26 PM
To: 'ReactOS Development List'
Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1

Hi Olaf,

 

You understood it correctly; the idea is graphically show an up-to-date
localization status report. Not only which modules are translated to each
language, but also if any of the localizations is "dirty" (meaning that
exists but contains new unlocalized strings). It will make the task of
maintaining updated translations easier.

 

/marc

 


  _____  


From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
Behalf Of Olaf Siejka
Sent: Sunday, November 04, 2007 11:11 PM
To: ros-dev(a)reactos.org
Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1

 


- Declarative module localizations : Now module localizations are created in
a declarative way which makes trivial tasks like listing non existent or
outdated language localizations in real time  for example :

http://www.codexchange.net/rosdoc/localizations.htm

Let me know your opinions and suggestions as I would like to start finishing
some of this features and merge all/part of my changes back to trunk 


I find this part extremely important. It would allow real-time tracking of
translation progress/status (if i understood it correctly) which would
greatly help maintain all the growing ROS localizations and help all ROS
translating teams. Such webpage, as you presented here, should be created on
ROS website as soon as it would be possible.

[Colin Finck]

Hi Marc,

>   Marc Piulachs wrote:
>  Is the online service application finished? Or even seriously planned? 
Will be
available in the following 2 , 4 or 6 months? I think the question
is: If current localization process can be *really* improved should we do
nothing till the online service is ready?

I don't think that we shouldn't do anything and currently I also propose
your solution as it seems to be nearly finished and should help us a lot.
Probably your solution also doesn't interfere with the Web Translation Tool.

If I recall correctly, the planned Web Translator shall convert the RC files
into XML files, which can later be edited online with the RosCMS Interface.
Then the RosCMS Interface also tracks the status of all translations.

I just asked, because Klemens or Magnus might have an update on their Web
Translation Tool.
Maybe we can combine the best of both proposals.

Regards,

Colin

[Magnus Olsen]

Hi marc
the plan online server aleady have that support. 
it make a rc file to xml file then transport it to online
servers, then the online server re translate it to rc and
do auto commit to svn. It extream complex system
allot part are being tested. and we need fixing 
the current bugs in the system before it can go
online. 
 
  ----- Original Message ----- 
  From: Marc Piulachs 
  To: 'ReactOS Development List' 
  Sent: Monday, November 05, 2007 4:40 PM
  Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1


  Hi Colin,

   

  I don't have an answer to your question but can make two considerations:

   

  -          Is the online service application finished? Or even seriously planned? Will
be available in the following 2 , 4 or 6 months? I think the question is: If current
localization process can be *really* improved should we do nothing till the online service
is ready?

  -          If my proposed solutions is adopted just as a intermediate solution while we
wait for the online service to be completed all the efforts made will be worth it as we
can generate a xml report from it and import them to the online service database with
ease.

   

  /marc

   


------------------------------------------------------------------------------

  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of
Colin Finck
  Sent: Monday, November 05, 2007 3:44 PM
  To: 'ReactOS Development List'
  Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1

   

  The open question would be: What happens with the already planned/prepared online
translation service?

  It also had a plan to improve the whole translation process, but as far as I know it
differs much from your solution.

   

  Klemens, Magnus, any comments on this?

   

  Regards,

   

  Colin

   

     


----------------------------------------------------------------------------

    From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of
Marc Piulachs
    Sent: Monday, November 05, 2007 2:26 PM
    To: 'ReactOS Development List'
    Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1

    Hi Olaf,

     

    You understood it correctly; the idea is graphically show an up-to-date localization
status report. Not only which modules are translated to each language, but also if any of
the localizations is "dirty" (meaning that exists but contains new unlocalized
strings). It will make the task of maintaining updated translations easier.

     

    /marc

     


----------------------------------------------------------------------------

    From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of
Olaf Siejka
    Sent: Sunday, November 04, 2007 11:11 PM
    To: ros-dev(a)reactos.org
    Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1

     


      - Declarative module localizations : Now module localizations are created in
      a declarative way which makes trivial tasks like listing non existent or
      outdated language localizations in real time  for example :

      http://www.codexchange.net/rosdoc/localizations.htm

      Let me know your opinions and suggestions as I would like to start finishing
      some of this features and merge all/part of my changes back to trunk 


    I find this part extremely important. It would allow real-time tracking of translation
progress/status (if i understood it correctly) which would greatly help maintain all the
growing ROS localizations and help all ROS translating teams. Such webpage, as you
presented here, should be created on ROS website as soon as it would be possible. 



------------------------------------------------------------------------------


  _______________________________________________
  Ros-dev mailing list
  Ros-dev(a)reactos.org
  http://www.reactos.org/mailman/listinfo/ros-dev

[Magnus Olsen]

  ----- Original Message ----- 
  From: Colin Finck 
  To: 'ReactOS Development List' 
  Sent: Monday, November 05, 2007 3:43 PM
  Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1


  The open question would be: What happens with the already planned/prepared online
translation service?
  It also had a plan to improve the whole translation process, but as far as I know it
differs much from your solution.

  Klemens, Magnus, any comments on this?

  Regards,

  Colin




----------------------------------------------------------------------------
    From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of
Marc Piulachs
    Sent: Monday, November 05, 2007 2:26 PM
    To: 'ReactOS Development List'
    Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1


    Hi Olaf,

     

    You understood it correctly; the idea is graphically show an up-to-date localization
status report. Not only which modules are translated to each language, but also if any of
the localizations is "dirty" (meaning that exists but contains new unlocalized
strings). It will make the task of maintaining updated translations easier.

     

    /marc

     


----------------------------------------------------------------------------

    From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of
Olaf Siejka
    Sent: Sunday, November 04, 2007 11:11 PM
    To: ros-dev(a)reactos.org
    Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1

     


      - Declarative module localizations : Now module localizations are created in
      a declarative way which makes trivial tasks like listing non existent or
      outdated language localizations in real time  for example :

      http://www.codexchange.net/rosdoc/localizations.htm

      Let me know your opinions and suggestions as I would like to start finishing
      some of this features and merge all/part of my changes back to trunk 


    I find this part extremely important. It would allow real-time tracking of translation
progress/status (if i understood it correctly) which would greatly help maintain all the
growing ROS localizations and help all ROS translating teams. Such webpage, as you
presented here, should be created on ROS website as soon as it would be possible. 



------------------------------------------------------------------------------


  _______________________________________________
  Ros-dev mailing list
  Ros-dev(a)reactos.org
  http://www.reactos.org/mailman/listinfo/ros-dev

[Magnus Olsen]

Hi
It is still under devloping and havy it will problare be ready next year, 
it is very complex system, we do not want anything goes wrong. 
it will not letting translator tuch the rc syntax, and best of part
it allown any dev only change the english rc file and thuse change
will automatic merges to other langues as well, 
 
  ----- Original Message ----- 
  From: Colin Finck 
  To: 'ReactOS Development List' 
  Sent: Monday, November 05, 2007 3:43 PM
  Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1


  The open question would be: What happens with the already planned/prepared online
translation service?
  It also had a plan to improve the whole translation process, but as far as I know it
differs much from your solution.

  Klemens, Magnus, any comments on this?

  Regards,

  Colin




----------------------------------------------------------------------------
    From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of
Marc Piulachs
    Sent: Monday, November 05, 2007 2:26 PM
    To: 'ReactOS Development List'
    Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1


    Hi Olaf,

     

    You understood it correctly; the idea is graphically show an up-to-date localization
status report. Not only which modules are translated to each language, but also if any of
the localizations is "dirty" (meaning that exists but contains new unlocalized
strings). It will make the task of maintaining updated translations easier.

     

    /marc

     


----------------------------------------------------------------------------

    From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On Behalf Of
Olaf Siejka
    Sent: Sunday, November 04, 2007 11:11 PM
    To: ros-dev(a)reactos.org
    Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1

     


      - Declarative module localizations : Now module localizations are created in
      a declarative way which makes trivial tasks like listing non existent or
      outdated language localizations in real time  for example :

      http://www.codexchange.net/rosdoc/localizations.htm

      Let me know your opinions and suggestions as I would like to start finishing
      some of this features and merge all/part of my changes back to trunk 


    I find this part extremely important. It would allow real-time tracking of translation
progress/status (if i understood it correctly) which would greatly help maintain all the
growing ROS localizations and help all ROS translating teams. Such webpage, as you
presented here, should be created on ROS website as soon as it would be possible. 



------------------------------------------------------------------------------


  _______________________________________________
  Ros-dev mailing list
  Ros-dev(a)reactos.org
  http://www.reactos.org/mailman/listinfo/ros-dev

[Timo Kreuzer]

Both solutions are good for different things. The online service for
providing an interface to do translations and to make sure that every
change in the english rc is also merged into the other languages. Marcs
solution is to keep track of the rc files and their translation status.
I think both should work together quite well. I even think that Marc's
solution is kinda needed for the online translation service. Or how does
it keep track of the rc files? You would probably need to update the
pathes everytime you change something, like moving a module. If rbuild
can produce an xml output, this wouldn't be neccesary.
How will it work if you want to add a new translation online? In the
current way of handling rc files it would need to change the rsrc file,
with Marc's solution it would need to change the rbuild file (at least
if I understood it correctly).
If you update the English rc file online, it would be neccessary that
all other .rc files are somehow marked dirty, because the file date
wouldn't work anymore when the changes are merged into all other rc's.

Another advantage of Marc's solution is that it would make it possible
to compile only those languages that you want. If you don't want a
translation for some languages, switch them off in the config.rbuild.

Regards,
Timo

Colin Finck schrieb:
>   The open question would be: What happens with the
> already
>  planned/prepared online translation service?
>  It also had a plan to improve the whole translation process, but as
>  far as I know it differs much from your solution.
>   
>  Klemens, Magnus, any comments on this?
>   
>  Regards,
>   
>  Colin

[Magnus Olsen]

HI
it is not need it, for the online system keeping track on the rc files
in the trunk. and not all modules can be translate, we need manual 
tell which module are ready for translate, this will get less 
headic for allot devloper like Ged when he doing new apps 
to ReactOS, so the translator does not start doing translate 
until it is up on the website. xml output for rbuild is not need it
is will take longer time build reactos, and that I am againts
wait and see what tne system gives and how it works.
I do not want review everthing how it works until it is online
frik85 known the web part allot better, he allown wrote the gui
and parser back xml to rc.
 
  ----- Original Message ----- 
  From: Timo Kreuzer 
  To: ReactOS Development List 
  Sent: Wednesday, November 07, 2007 12:19 PM
  Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1


  Both solutions are good for different things. The online service for providing an
interface to do translations and to make sure that every change in the english rc is also
merged into the other languages. Marcs solution is to keep track of the rc files and their
translation status. I think both should work together quite well. I even think that
Marc's solution is kinda needed for the online translation service. Or how does it
keep track of the rc files? You would probably need to update the pathes everytime you
change something, like moving a module. If rbuild can produce an xml output, this
wouldn't be neccesary.
  How will it work if you want to add a new translation online? In the current way of
handling rc files it would need to change the rsrc file, with Marc's solution it would
need to change the rbuild file (at least if I understood it correctly).
  If you update the English rc file online, it would be neccessary that all other .rc
files are somehow marked dirty, because the file date wouldn't work anymore when the
changes are merged into all other rc's.

  Another advantage of Marc's solution is that it would make it possible to compile
only those languages that you want. If you don't want a translation for some
languages, switch them off in the config.rbuild.

  Regards,
  Timo

  Colin Finck schrieb: 
    The open question would be: What happens with the already planned/prepared online
translation service? 
    It also had a plan to improve the whole translation process, but as far as I know it
differs much from your solution. 

    Klemens, Magnus, any comments on this? 

    Regards, 

    Colin 




------------------------------------------------------------------------------


  _______________________________________________
  Ros-dev mailing list
  Ros-dev(a)reactos.org
  http://www.reactos.org/mailman/listinfo/ros-dev

[Colin Finck]

Magnus Olsen wrote:
>   xml output for rbuild is not need it is will take
> longer time build 
reactos

Marc just suggested to include that as a feature for rbuild and I guess he
did not mean that it will output an XML file on every build.
I assume, the feature would work like i.e. the MSVC project file output,
which is also only activated, when you type "make msvc*"


>   I do not want review everthing how it works until it
> is online 
I don't want to sound rude now, but it would be nice if some more details of
your planned interface would be published, so everyone could think about
them.

For example, I wonder how you want to deal with stuff like dialogs in
resource files.
>  From what I understood, there will only be one file
> containing the 
definitions for all languages and the language files then contain
the
translated strings. But for example what do you do, when a dialog control
needs different metrics in different languages?
This can happen quite often.

For the rest, I agree with Timo that both solutions are helpful and should
be integrated.
Especially excluding languages I don't need from the build is a feature I
would like to see added.

Regards,

Colin

[Magnus Olsen]

you will be avail see the dialog box and resize it online, if it need it.
or was it auto resize in the frist version, both featuer is plan,
and one of them are already implemnent

----- Original Message ----- 
From: "Colin Finck" <mail(a)colinfinck.de>
To: "'ReactOS Development List'" <ros-dev(a)reactos.org>
Sent: Wednesday, November 07, 2007 4:46 PM
Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1


>   Magnus Olsen wrote:
> >   xml output for rbuild is not need it is will take
> > longer time build 
>  reactos
>
>  Marc just suggested to include that as a feature for rbuild and I guess he
>  did not mean that it will output an XML file on every build.
>  I assume, the feature would work like i.e. the MSVC project file output,
>  which is also only activated, when you type "make msvc*"
>
>
> >   I do not want review everthing how it works until
> > it is online 
>  I don't want to sound rude now, but it would be nice if some more details 
>  of
>  your planned interface would be published, so everyone could think about
>  them.
>
>  For example, I wonder how you want to deal with stuff like dialogs in
>  resource files.
> >  From what I understood, there will only be one
> > file containing the 
>  definitions for all languages and the language files then
> contain the
>  translated strings. But for example what do you do, when a dialog control
>  needs different metrics in different languages?
>  This can happen quite often.
>
>  For the rest, I agree with Timo that both solutions are helpful and should
>  be integrated.
>  Especially excluding languages I don't need from the build is a feature I
>  would like to see added.
>
>  Regards,
>
>  Colin
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Marc Piulachs]

Hi Magnus,

 

A few comments under your own lines:

 

>  it is not need it, for the online system keeping track
> on the rc files 
>  in the trunk. and not all modules can be translate, we
> need manual 
> tell which module are ready for translate, this will get less  
>  headic for allot devloper like Ged when he doing new
> apps 
> to ReactOS, so the translator does not start doing translate 
> until it is up on the website.  
 

If that's the problem it can be easily solved adding a new optional
attribute "localizable" that defaults to true so to avoid even being listed
in reports:

 

<localization isoname="en-US"
localizable="false">lang/en-US.rc</localization>

 

>   xml output for rbuild is not need it is will take
> longer time build 
reactos,

 

This xml was meant to be generated under request (Backend), think it as an
export feature rather than standard build option, anyway your point does not
make sense to me as rbuild has already a tree-in-memory structure with all
the information required, generating an xml file takes literally 1 second
(in case you are not building ros on a 386 SX :-) )

 

>   and that I am againts
>  wait and see what tne system gives and how it works. 
>   I do not want review everthing how it works until it
> is online 
>   frik85 known the web part allot better, he allown
> wrote the gui 
>   and parser back xml to rc. 
 

IMHO my proposed solution represents a significant improvement over the
current situation and most important is ready to be used and is
complementary rather than mutually exclusive. Saying that you are against it
because the online solution is better without even sharing concrete
information about it does not really sound very constructive to me.

 

Regards,

/Marc

 

----- Original Message ----- 

From: Timo Kreuzer <mailto:[e-mail]>  

To: ReactOS <mailto:[e-mail]>  Development List 

Sent: Wednesday, November 07, 2007 12:19 PM

Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1

 

Both solutions are good for different things. The online service for
providing an interface to do translations and to make sure that every change
in the english rc is also merged into the other languages. Marcs solution is
to keep track of the rc files and their translation status. I think both
should work together quite well. I even think that Marc's solution is kinda
needed for the online translation service. Or how does it keep track of the
rc files? You would probably need to update the pathes everytime you change
something, like moving a module. If rbuild can produce an xml output, this
wouldn't be neccesary.
How will it work if you want to add a new translation online? In the current
way of handling rc files it would need to change the rsrc file, with Marc's
solution it would need to change the rbuild file (at least if I understood
it correctly).
If you update the English rc file online, it would be neccessary that all
other .rc files are somehow marked dirty, because the file date wouldn't
work anymore when the changes are merged into all other rc's.

Another advantage of Marc's solution is that it would make it possible to
compile only those languages that you want. If you don't want a translation
for some languages, switch them off in the config.rbuild.

Regards,
Timo

Colin Finck schrieb: 



The open question would be: What happens with the already planned/prepared
online translation service? 

It also had a plan to improve the whole translation process, but as far as I
know it differs much from your solution. 

 

Klemens, Magnus, any comments on this? 

 

Regards, 

 

Colin 

 


  _____  


_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[Magnus Olsen]

HI
what we really need is the MUI system in reactos, it will do as u like
as I expain in the last letter I post, But at moment is the MUI low priror.
When the MUI are inplace we simple will split out all langues to own
dll/exe/sys files, like ms does for server addons for diffnet langues
ms name the file programname_langues_mui.* if I rember right from my head
without looking now. The langues will come like plugins to ReactOS.
so we need gdi and other part ready and MUI api full implement before 
we can do it, 
 
  ----- Original Message ----- 
  From: Marc Piulachs 
  To: 'ReactOS Development List' 
  Sent: Wednesday, November 07, 2007 5:57 PM
  Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1


  Hi Magnus,

   

  A few comments under your own lines:

   

>  it is not need it, for the online system keeping track
> on the rc files 
>  in the trunk. and not all modules can be translate, we
> need manual 
> tell which module are ready for translate, this will get less  
>  headic for allot devloper like Ged when he doing new
> apps 
> to ReactOS, so the translator does not start doing translate 
> until it is up on the website.  
   

  If that's the problem it can be easily solved adding a new optional attribute
"localizable" that defaults to true so to avoid even being listed in reports:

   

  <localization isoname="en-US"
localizable="false">lang/en-US.rc</localization>

   

>   xml output for rbuild is not need it is will take
> longer time build reactos, 
   

  This xml was meant to be generated under request (Backend), think it as an export
feature rather than standard build option, anyway your point does not make sense to me as
rbuild has already a tree-in-memory structure with all the information required,
generating an xml file takes literally 1 second (in case you are not building ros on a 386
SX J )

   

>   and that I am againts
>  wait and see what tne system gives and how it works. 
>   I do not want review everthing how it works until it
> is online 
>   frik85 known the web part allot better, he allown
> wrote the gui 
>   and parser back xml to rc. 
   

  IMHO my proposed solution represents a significant improvement over the current
situation and most important is ready to be used and is complementary rather than mutually
exclusive. Saying that you are against it because the online solution is better without
even sharing concrete information about it does not really sound very constructive to me.

   

  Regards,

  /Marc

   

    ----- Original Message ----- 

    From: Timo Kreuzer 

    To: ReactOS Development List 

    Sent: Wednesday, November 07, 2007 12:19 PM

    Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1

     

    Both solutions are good for different things. The online service for providing an
interface to do translations and to make sure that every change in the english rc is also
merged into the other languages. Marcs solution is to keep track of the rc files and their
translation status. I think both should work together quite well. I even think that
Marc's solution is kinda needed for the online translation service. Or how does it
keep track of the rc files? You would probably need to update the pathes everytime you
change something, like moving a module. If rbuild can produce an xml output, this
wouldn't be neccesary.
    How will it work if you want to add a new translation online? In the current way of
handling rc files it would need to change the rsrc file, with Marc's solution it would
need to change the rbuild file (at least if I understood it correctly).
    If you update the English rc file online, it would be neccessary that all other .rc
files are somehow marked dirty, because the file date wouldn't work anymore when the
changes are merged into all other rc's.

    Another advantage of Marc's solution is that it would make it possible to compile
only those languages that you want. If you don't want a translation for some
languages, switch them off in the config.rbuild.

    Regards,
    Timo

    Colin Finck schrieb: 

    The open question would be: What happens with the already planned/prepared online
translation service? 

    It also had a plan to improve the whole translation process, but as far as I know it
differs much from your solution. 

     

    Klemens, Magnus, any comments on this? 

     

    Regards, 

     

    Colin 

     


----------------------------------------------------------------------------

    _______________________________________________
    Ros-dev mailing list
    Ros-dev(a)reactos.org
    http://www.reactos.org/mailman/listinfo/ros-dev



------------------------------------------------------------------------------


  _______________________________________________
  Ros-dev mailing list
  Ros-dev(a)reactos.org
  http://www.reactos.org/mailman/listinfo/ros-dev

[Marc Piulachs]

Hi,

 

I think we should be a little more pragmatic here, you talk about long term
goal (MUI) which is out of discussion for now .If a change is available
today and represents a significant improvement I think its better to use it
rather than do nothing and wait for the perfect solution (see my change as
1.0 , online translation as 2.0 and MUI as 3.0) , and once again , my
proposed solution is not any radical change only a way to DESCRIBE the
available localizations for a given module an its current state, once you
have this up-to-date information you can do whatever you want with it ,
generate an xml or html report , import it to a custom designed database or
even autogenerate source code/new resource files or dlls (MUI) out of it.

 

/marc

 

  _____  

From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
Behalf Of Magnus Olsen
Sent: Thursday, November 08, 2007 12:02 AM
To: ReactOS Development List
Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1

 

HI

what we really need is the MUI system in reactos, it will do as u like
as I expain in the last letter I post, But at moment is the MUI low priror.
When the MUI are inplace we simple will split out all langues to own

dll/exe/sys files, like ms does for server addons for diffnet langues

ms name the file programname_langues_mui.* if I rember right from my head
without looking now. The langues will come like plugins to ReactOS.
so we need gdi and other part ready and MUI api full implement before 
we can do it, 

 

----- Original Message ----- 

From: Marc Piulachs <mailto:[e-mail]>  

To: 'ReactOS Development List' <mailto:[e-mail]>  

Sent: Wednesday, November 07, 2007 5:57 PM

Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1

 

Hi Magnus,

 

A few comments under your own lines:

 

>  it is not need it, for the online system keeping track
> on the rc files 
>  in the trunk. and not all modules can be translate, we
> need manual 
> tell which module are ready for translate, this will get less  
>  headic for allot devloper like Ged when he doing new
> apps 
> to ReactOS, so the translator does not start doing translate 
> until it is up on the website.  
 

If that's the problem it can be easily solved adding a new optional
attribute "localizable" that defaults to true so to avoid even being listed
in reports:

 

<localization isoname="en-US"
localizable="false">lang/en-US.rc</localization>

 

>   xml output for rbuild is not need it is will take
> longer time build 
reactos,

 

This xml was meant to be generated under request (Backend), think it as an
export feature rather than standard build option, anyway your point does not
make sense to me as rbuild has already a tree-in-memory structure with all
the information required, generating an xml file takes literally 1 second
(in case you are not building ros on a 386 SX :-) )

 

>   and that I am againts
>  wait and see what tne system gives and how it works. 
>   I do not want review everthing how it works until it
> is online 
>   frik85 known the web part allot better, he allown
> wrote the gui 
>   and parser back xml to rc. 
 

IMHO my proposed solution represents a significant improvement over the
current situation and most important is ready to be used and is
complementary rather than mutually exclusive. Saying that you are against it
because the online solution is better without even sharing concrete
information about it does not really sound very constructive to me.

 

Regards,

/Marc

 

----- Original Message ----- 

From: Timo Kreuzer <mailto:[e-mail]>  

To: ReactOS <mailto:[e-mail]>  Development List 

Sent: Wednesday, November 07, 2007 12:19 PM

Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1

 

Both solutions are good for different things. The online service for
providing an interface to do translations and to make sure that every change
in the english rc is also merged into the other languages. Marcs solution is
to keep track of the rc files and their translation status. I think both
should work together quite well. I even think that Marc's solution is kinda
needed for the online translation service. Or how does it keep track of the
rc files? You would probably need to update the pathes everytime you change
something, like moving a module. If rbuild can produce an xml output, this
wouldn't be neccesary.
How will it work if you want to add a new translation online? In the current
way of handling rc files it would need to change the rsrc file, with Marc's
solution it would need to change the rbuild file (at least if I understood
it correctly).
If you update the English rc file online, it would be neccessary that all
other .rc files are somehow marked dirty, because the file date wouldn't
work anymore when the changes are merged into all other rc's.

Another advantage of Marc's solution is that it would make it possible to
compile only those languages that you want. If you don't want a translation
for some languages, switch them off in the config.rbuild.

Regards,
Timo

Colin Finck schrieb: 



The open question would be: What happens with the already planned/prepared
online translation service? 

It also had a plan to improve the whole translation process, but as far as I
know it differs much from your solution. 

 

Klemens, Magnus, any comments on this? 

 

Regards, 

 

Colin 

 


  _____  


_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


  _____  


_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[Marc Piulachs]

Hi Timo,



(.)


>  Another advantage of Marc's solution is that it
> would make it possible to 
compile only those languages that you want. If you
don't want a translation
>  for some languages, switch them off in the
> config.rbuild. 
 

Exacly . that's one of the planed features , if you take a look at my branch
you will see I introduced a new element "language" that complements the also
new "localization" element we are discussing. The "language" element
is used
to explicitly declare what languages is reactos available (meaning at least
one rc is available somewhere in that language) , this functionality is
required to validate the "isoname" attribute on "localization"
elements but
also in the future to fill part of the languages information on txtsetup.sif
(see http://www.reactos.org/bugzilla/show_bug.cgi?id=2635)  . so you will be
able to just comment the languages you don't want to include in the build in
languages.rbuild (see
http://svn.reactos.org/svn/reactos/branches/rbuild/reactos/languages.rbuild?
revision=30209
<http://svn.reactos.org/svn/reactos/branches/rbuild/reactos/languages.rbuild
?revision=30209&view=markup> &view=markup ) and apart from not being
compiled and included in your OS image they will disappear from setup
automatically.

 

Regards,
/Marc


Colin Finck schrieb: 


The open question would be: What happens with the already planned/prepared
online translation service? 

It also had a plan to improve the whole translation process, but as far as I
know it differs much from your solution. 

 

Klemens, Magnus, any comments on this? 

 

Regards, 

 

Colin

[Magnus Olsen]

Hi
diffent langues will change later to MUI system, 
it mean we will have a extra dll / exe file for each program that contain the
right langues, that split will come later in reactos, it mean the rc file 
for other langues will endup in the MUI folder, like windows does,
it allown us change the langues at runtime. and one more thing 
the build time will go down, if we do the MUI as rosapps or simluare
there u choice which langues u want, it is futuer plans when 
ReactOS support MUI, at moment we do not, 

  ----- Original Message ----- 
  From: Marc Piulachs 
  To: 'ReactOS Development List' 
  Sent: Wednesday, November 07, 2007 5:27 PM
  Subject: Re: [ros-dev] Ros-dev Digest, Vol 39, Issue 1


  Hi Timo,



  (.)


>  Another advantage of Marc's solution is that it
> would make it possible to compile only those languages that you want. If you don't
> want a translation >for some languages, switch them off in the config.rbuild. 
   

  Exacly . that's one of the planed features , if you take a look at my branch you
will see I introduced a new element "language" that complements the also new
"localization" element we are discussing. The "language" element is
used to explicitly declare what languages is reactos available (meaning at least one rc is
available somewhere in that language) , this functionality is required to validate the
"isoname" attribute on "localization" elements but also in the future
to fill part of the languages information on txtsetup.sif (see
http://www.reactos.org/bugzilla/show_bug.cgi?id=2635)  . so you will be able to just
comment the languages you don't want to include in the build in languages.rbuild (see
http://svn.reactos.org/svn/reactos/branches/rbuild/reactos/languages.rbuild…
) and apart from not being compiled and included in your OS image they will disappear from
setup automatically.

   

  Regards,
  /Marc


  Colin Finck schrieb: 

  The open question would be: What happens with the already planned/prepared online
translation service? 

  It also had a plan to improve the whole translation process, but as far as I know it
differs much from your solution. 

   

  Klemens, Magnus, any comments on this? 

   

  Regards, 

   

  Colin 

   



------------------------------------------------------------------------------


  _______________________________________________
  Ros-dev mailing list
  Ros-dev(a)reactos.org
  http://www.reactos.org/mailman/listinfo/ros-dev

[Timo Kreuzer]

I think the rbuild part will then do a good job in creating the
additional files without the need to change the whole resource related
code in the tree. Another good reason to implement it now.


Magnus Olsen wrote:
>   Hi
>  diffent langues will change later to MUI system,
>  [...]