View previous topic :: View next topic |
Author |
Message |
sheitman
Joined: 27 Apr 2010 Posts: 98
|
Posted: Thu Mar 31, 2011 10:26 am Post subject: Looking for a concept for 2 dev branches with translation |
|
|
Hi
I have 2 branches, one for releases and one for pre-releases.
Currently I am translating the release branch however I have to be able to get my translations earlier that means I have to translate my pre-release branch to.
The pre-release branch contains developed features which are deployed to beta testers and every 8 weeks we merge them into the release branch.
On the other side pre-release coudl change on a weekly basis.
I thougth I could have a globalizer file for each branch which is also under source control however I think I will get some trouble on merging when I changed some typo in the release branch and have some heavy modified pre-release. As the globalizer file is a xml file and my experience is that xml files can be really hard to merge especially if there were a lot of changes.
Another way would be to have 2 globalizer files, one for the release and one for the pre-release. However I would loose the translations between this two files on scanning as you told me globalizer is designed in that way that there is only one file for translation and that globalizer is the tool to do translations because its tracking them.
I also thougth about only using a translation file for pre-release however that would mean I could not fix typos or do a translation of a specific release into a new language. I would be dependend on the pre-release which is changing on a weekly basis. So I could not merge them often to release, of couse.
Do you have some idea what I could do?
Kind regards,
Sven |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Thu Mar 31, 2011 10:06 pm Post subject: |
|
|
My own preference would be for a single Globalizer file under source control. You are right that there is always the potential for something to go wrong when merging changes, however, my experience with merging Globalizer xml files between different CVS branches has not been bad. The structure of the Globalizer xml file probably makes it easier for merge tools to handle correctly.
The second option is to have two separate files - however instead of scanning each time with "Scan All Cultures" option turned on (which you were doing before) just scan the project normally (ie Invariant only). Then to merge translations from the other Globalizer file you can use the File->Import function. _________________ Infralution Support |
|
Back to top |
|
|
sheitman
Joined: 27 Apr 2010 Posts: 98
|
Posted: Fri Apr 01, 2011 7:31 am Post subject: |
|
|
Infralution wrote: | My own preference would be for a single Globalizer file under source control. You are right that there is always the potential for something to go wrong when merging changes, however, my experience with merging Globalizer xml files between different CVS branches has not been bad. The structure of the Globalizer xml file probably makes it easier for merge tools to handle correctly.
The second option is to have two separate files - however instead of scanning each time with "Scan All Cultures" option turned on (which you were doing before) just scan the project normally (ie Invariant only). Then to merge translations from the other Globalizer file you can use the File->Import function. |
Good morning.
You second option is similar to the idea that came into my mind yesterday on the way to home from my work^^
I use this at the moment to get english translations into my finnish file. I think I will try this approach.
Thanks for your help |
|
Back to top |
|
|
|