You don't need to be an 'investor' to invest in Singletrack: 6 days left: 95% of target - Find out more
I have an operating manual that is currently at revision A03.
I have just had it translated into French. Should the manual inherit the revision status of the English version it was based on or should it be A00 as it is the first release of a French version?
I have my own thoughts but I'll hold them back so they don't influence your own.
Thanks!
Good question, and one I've asked for the same reason. My view is that it's a new document so should have its own issue number, but when you up-issue the English version and get it re-translated that will also bump the french issue number.
You will need to keep a record of what issue number of the original was used for the translation somewhere, and the issues will get out of sync, but as I said, they are different documents.
I had to deal with about 5 different languages once!
It should be F03 - same version NUMBER as the english from which it was translated, but different prefix to signify a translation
Call it A03FR. So people can easily see it's the French version of A03.
But what happens if there's a change just to the French version?
I'd go (and we do where neded) with want pandhandj said. Do you use a document control software that monitors revision dates and reviews -we use a system called ACTIVE, though doc control is only part of it https://www.myactiv.co.uk/ .
Interesting problem...
The French version may end up needing corrections to the French bit, so it's minor reference number will increment independently from the English master one, so you need a solution which allows for each to have different minor versions.
I'd call it A03 so it's clear which other language version(s) it's aligned to but then have something like A03a/b/c/d etc. to track (likely only translation related) revisions specific to it - unless the doc is going to be entirely maintained as it's own thing after the initial version (might depend on whether it's a pure translation or if it's amended for local country regulations etc. as well)
But what happens if there’s a change just to the French version?
You have to determine which is the master which drives the content in the others (children).
I think it's not a good idea to add letters to your revision text just to 'fix' a specific problem (and whatever system you have may not allow it anyway).
If your revision is letter,number keep it like that.
Not in my opinion.
Once you start adding things it gets out of control. It's hard to manage, it's a pain when you want to search for a particular issue, and you don't even know how many characters it is, or you leave space for, say, 6 characters in a form, and someones made a 10 character code!
And don't get me started on part numbers!
Lol!
I was going to drop in parts numbers next, just to lighten the mood a wee bit :):):)
In my regulated world, you start with a 'Source language' (in this case English) and then the French is a child of the source document, so you'd add an extension to the file name (AXXFR). In my world you shouldn't have a scenario where to child documents differ in content, just localization/translation.
If the child document MUST change then it becomes it's own document and therefore has it's own naming convention (FRXX)
I'd go with what Cokie says, but the correct answer is: "what does the SOP say?".
I'd call it A303 - particularly if starts with a lot of promise, gets a bit difficult in the middle but then ends quite nicely.
A03.FR01
But what happens if there’s a change just to the French version?
You have to decide whether it's a French language version of the policy (French version should not diverge in content from original policy) or a France adaptation of the policy (it may sail its own way).
Controversial suggestion is the power tool instructions approach: the English text is the first 5 pages of the policy, the French text is the next 5 pages of the same policy, then Hungarian is the next 5 pages...but it's all the same document, policy and version number.
I've seen legal documents split into two language columns which could work, but won't be scalable to a third language so probably not practical depending on future requirements...
A bit like this...
https://qph.cf2.quoracdn.net/main-qimg-39b79fa37a1c8ef36bde1c2a7090a930-lq
Would it not be A04? That way you keep the reference to the parent document and register the change in the change log?
@maatyfez
I’ve seen legal documents split into two language columns which could work
I'm currently reviewing one that is in Russian & English. I don't know who thought it would be a good idea, it began with Russian on the left but every now and again it switches side. Plus It looks like it has been translated with some translation software as it gives several different translated words for the same Russian word. It's an official released document but our customer as well.. Augh!! It's driving me mad.
The French one is it's own document Manual_FR with it's own document revision. Sure it started life as a translation of Manual-EN rev A03 but it now has its own life and will have revisions separate to the master. If the EN is revised the FR should follow and this could be mentioned in the version history "doc updated with changes to specific blah blah, synchronised with doc_EN rev A07"
he English text is the first 5 pages of the policy, the French text is the next 5 pages of the same policy,
If the English is 5 pages, the French would probably be 7 or 8! English is very, very concise.
Turn it into an NFT. Then it is its own revision.
And as a bonus your friends can invest in it and lose all their savings.
Naming it with a different number brings it's own problems as well, how do you know which revision it's based on? Unless you have a reference section where you can refer back to the parent document.
As for minor changes our numbering allows for A,B,C suffixes after the major revision number. So 003 would be revision 3 and 003C would be 3 minor changes later. That's where I would go pushing minor grammar fixes and the like through as minor changes (why would it be anything else if the intent and use hasn't changed?).
You should also have a robust verification and approval system so bullshit changes aren't continually needed. We go
Author
Doc Centre (for formatting and checking correct templates etc.)
Verifier
Approver
we do
author
peer review
lodge in development change control
local checking utility
formal review
record evidence, lodge in change control
update doc as needed for release
lodge in development change control
release centre approvals
lodge in productiuon release control
and still wind up with bullshit changes, because you can't fix humans