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@reactos.org [mailto:ros-dev-bounces@reactos.org] 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

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@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev


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