Long shot, but worth a try.
Get everyone to check in their copies.
Everyone deletes their cpd file.
One person checks out the entire project and changes the language.
Check in the entire project and delete the cpd.
Get Specific Version ( latest, and tick overwrite, etc options to force a get of the latest (assuming TFS, long story, don't ask))
Open the project and see if the problem persists.
An additional step that can be inserted before Get Specific Version is actually deleting the current folders off the disk, to ensure there are no old files lingering.
(and the cpd definitely isn't in source control right?)
Firstly the CPD is not under source control and is also set to re-generate every time which dates from the RH 8.0.2 era.
So I'm thinking not the CPD??
Is the setting per project or per user/RH installation? I was thinking that perhaps someone's cpd is "remembering" the language setting and re-writing it each time they open the project. But if the setting is definitely on the project, not the installation, then the above is unlikely to help.
In answer to both your questions, Yes!
The project is set in both places to for example UK English the project is saved and checked in.
When the project is checked out again the Project settings option has reverted to US English unprompted while the Tools > Options setting remnains at UK English.
So at present every time I want to compile this project into a parent merged project I have to reset the Project Settings option other wise a message is displayed when opening the nparent project telling me that the project concerned has a different language setting..
What I meant to say was the cpd file is excluded from source control but the RH project is under TFS source control.
In fact the advice I received when I had to start using TFS was to exlcude certain files which applied to the local copy of the project cpd being one of them..
It looks like a reply I posted didn't survive the forum problems last Friday.
There are other files that should not be checked in and out, they are listed in Snippets on my site. However, this is looking more like a source control issue so perhaps Amber can come come back in?
See www.grainge.org for RoboHelp and Authoring tips
Yes, I already have things set up so that the files you recommend are not checked in and out...
Be interested to see what Ambr has to say...
Hmm, puzzling. Maybe it's being reset based on the Windows Locale?
Or perhaps change the project language to something, then back to UK English. Open the xpj in a text editor and check the number and make sure that number is checked in to source control - maybe it's being changed but not checked in correctly.
One other idea is to delete all the project files off all users PCs and do a fresh get to ensure there aren't some old files not being "got" - I know that Get Latest sometimes doesn't get the latest as it thinks everything is up to date. I'm not sure how that happens, unfortunately.
Just grasping at straws now, sorry.
We've done some more testing here and seem to have eliminated TFS as the problem. We did the following:
- Open project
- File > Project settings change top uk english
- Save all
- Close project but didn't check in so is outside TFS
- Opened project again - it has reverted to US English unprompted
BTW also tried deleting local copies of xpj with xpj checked in first but to no avail. I really don't want to have to create a new project and re-import everything.
I have had two senior developers look at this and both concluded it was nothing to do with TFS also.
Any further ideas?
Further to my last entry,
- Tried changing to uk english and closed. When checked with a text editor the xpj file was still showing language as 2057 which is uk English.
- Opened in RH again and checked setting it was reverted back to US
- also checked local copy with RHG still open with text editor said 1033 US English
So the act of opening the RH project is reverting it to US English for some reason which I cannot fathom...
Also checked windows locale and all is set to UK English. Running windows XP SP3
Thanks for your offer to take a look at the project.
As this is a new product and confidential that's a bit tricky but a colleague has copy of RH on their machine so will try running on that in the first instance and let youy know how we get on.
Hi again Peter,
I have been unbale to run it on another machine here so it would be helpful if you could take a look at the project (subject to usual confidentailituy etc.). Please can you send me a suitable link so I can contact you directly to arrange this or advise how best to proceed otherwise...
Hi, Author care.
Peter and I are ganging up to see if we can shed some light.
From previous posts, I know you are a power-user and you (and Amebr!) probably know more about this way more than I do, but let me offer a review of some tips you may have missed.
I'm also posting some things that you may already know, but for the sake of others who may stroll by this thread in the future.
I hope I'm not sending you on a wild goose chase. My thought is that if part of your UK English issue is because it is still somehow communicating with version control, I will outline some tips I've used in the past to make certain your project is truly disassociated with version control. Caveat: What I describe will result in your losing the source control History for that project, but for many authors this is not a real problem. Your mileage may vary.
First a review of the tips which MergeThis (Leon Descoteaux) and TheMarcus7 (Mark Whisler) and Amebr have offered over the years.
Third-party integration with RoboSource Control:
Configure the built-in RoboSource Control application with the third-party source control database. I believe in this case it is Team Foundation Server (TFS)
The means that commands such as Add to Version Control, Check-in, Check-out, etc. can be used within the RoboHelp UI toolbars, menus. The reason I mention this is because I have always understood that it is best practice to exercise Version Control commands *within the RoboHelp application interface* and not to open the third party VC application and move files manually to the RoboHelp working folder. The point being that RoboHelp will make the proper decision as to which files to check-in/out, etc. and better synchronize the projects.
Never add these files to version control:
Regardless, it's very important NOT to add these files to Source Control because they are "machine specific" and will always become corrupt.
If you add using RoboHelp's interface, it will avoid sending those to source control. But some people just add the whole project folder to source control (and the .cpd goes along for the ride) and that's where problems start. So if you continue to do it "manually" just be sure not to add those four files.
Manually "separating" a project from version control:
(Warning: You will lose your History record and thus you will be starting with a clean slate.)
There is a command called "Remove from version control". But sometimes this does not completely work. For troubleshooting it can be helpful to manually remove a project by modifying files according to Mark Whisler's method:
Make a copy of your project(s). Always work on copies unless you are REALLY sure of what you’re doing. The copy will still attempt to open the project from source control until you disassociate it.
To remove the copied projects from source control, follow these steps:
1. Use Windows Explorer to navigate to the directory containing the copied projects.
2. Select all the files inside the folder and turn off the Read Only attribute. (Right-click on the folder then click Properties. Turn off Read-Only and click Apply.)
3. Using Windows Explorer delete the following files from each project folder:
< projectname>. CPD
mssccprj.scc (If present)
4. Using Windows Explorer, locate the XML project file <projectname.XPJ> file for each project. This is the project file used by RoboHelp.
5. Using Notepad, open the <projectname.XPJ> file for each project and remove the section of code beginning with <miscproperties> and ending with </matchedpair>. Leave the </miscproperties> line present and untouched.
6. Change the </miscproperties> line by relocating the forward slash to the end of the line so that instead, it reads <miscproperties/>.
7. Close Windows Notepad and save the changes to the <projectname.XPJ> file.
Open each project archive in RoboHelp to verify that it is disassociated from source control.
Now to the main issue of changing the UK English Language file!
Once you are confident you have truly removed the project, go ahead and change the language as you did before. But this time it should not revert because it is no longer connected to source control.
Once you are confident that UK English is "sticking", then you can Add that project back to version control, knowing that it is working locally. I would place it in a new folder in version control or even create a clean new database for it. Open this and verify that UK English is still holding.
Sorry for the long song and dance here. I know you have been frustrated by this and hope this assists toward a solution. Meanwhile, I am going to report this thread to some Adobe engineers to see if I've missed anything.
Adobe Certified RoboHelp and Captivate Instructor
Hi John and Peter,
Thank you for your suggestions.
re - Third-party integration with RoboSource Control:
Yes we do the commands from within RoboHELP
re - Never add these files to version control:
We don't have any of these under source control
Manually "separating" a project from version control and testing it outside of version control.
This would seem to be the only solution short of creating a new project by importing the existing one.
What baffles me is that this behavior only occurs on this one project.
I'm not entirely convinced that it's a TFS problem as one fo the tests I did was to check out the xpj file, look at in text editor first and observed that it had the UK english language setting. But once the project was opened in robohelp the language flipped which could also be observed in the text editor version of the xpj file.
It's the opening of the project in Robohelp that seems to be kicking this off.
I will have a think about all this and decide which method to try.
I have now, thanks to the advice kindly offered by yourselves been able to create a copy of the project outside of TFS control.
I then renamed the project slightly as a precaution. Following this I was able to change and retain the language setting.
I then added the "new" project into TFS revsion control and it has worked properly so far. Will keep and eye on it this week and report back if further problems occur.
Many thanks all for your help.