Monday, May 31, 2010

Revit and Multi-Language Documents

Its been much too long since ive written. Its been an eventful year since i wrote last! I went through all of the implementation and content standards at a new job in NYS, right after which point.... I moved to Texas, to take the job as a BIM Manager at The Beck Group in Dallas. Its been a busy but amazing time down here, and im enjoying every minute of it.
On the Revit side, theres a lot of current stuff to write about. But this one struck my fancy. We're doing some Design Work in Korea, and as such our deliverables have to show both languages: English and Korean. We experimented with a few different options for this, and we also found some interesting things (some by accident). Heres how it went down:


There were two items that needed to have both languages: Room Names, and Notes. Room names was a pretty easy one. As most languages arent one for one literal translations, we simply needed another Parameter to put in the Room tag. No brainer there. Where it got interesting was the following:
In doing some experimenting, The room name in Korean had to be typed in a Text file, saved in UNICODE Encoding, instead of the standard ANSI (Notepad) or Western European/Windows (Word, saved as Plain Text). Without the Unicode Encoding, the characters would actually translate in to gibberish, and nothing would work. Ironically, we figured this meant we would also need a Font that had the Korean characters in it.




Initial testing proved this not to be the case, as this screen shot is Korean Text, in Arial. Interesting! However, i went over to a collegues station and his looked a bit different than mine:






The Korean Arial isnt displaying in Revit on his system. Whats the difference? Im on Windows7-64, and he is on Windows Vista-64.
For whatever reason, the Unicode TXT document doesnt respond the same on both systems.
This also made me nervous because of the Revit "Tug of war" that happens with some settings such as "By Linked view." (If youre not sure what i mean, with two users in a workshared project (Parent) with Links (Link), test the following:
Have both users get local copies of the workshared model, and local copies of the Linked Model.


1. User1: In "Link" Create a new view, "View-Link"
2. User1: SWC in "Link."
3. User1: In "Parent," reload "Link."
4. User1: In "Parent," set a view to "By Linked View: View-Link"
5. User1: Synchronize with Central
6. User2: (Who has been working this whole time): Sychronize with Central.
7. Either user- Go check the Linked View VG settings for Link in that view.

The trouble is, the instance of "Link" for User2 doesnt HAVE that "View-Link" yet, so it cannot acknowledge that it is "BLV:View-Link." Where this gets troublesome, is for some reason the local file of User2 acquires editability of those view settings, and UNDOES the Linked View.)

Back on topic, im HAPPY to report that isnt the issue with the Encoding of the Text in the parameters. So, if the Vista user sees it displayed as squares, it will still plot and display correctly, in Korean...... If plotted from a machine using Windows 7. (I dont think its a Revit issue, so much as a windows issue, but i dont know enough about it. Thats only amusing because Revit 2010 (what this project is in) isnt officially supported in Win7. FWIW: We would love to upgrade, but the Foreign Language versions of 2011 werent released in time for our consultants, hence remaining in 2010. But i digress: The inconsistancy in Windows versions and text occurs in 2011 as well.

This brought us to our next challenge: Notes, in both Korean and English. With language being something that we cant just "toogle" because of the indirect translation, we wanted some way to at least assure that the English and Korean versions stayed tied and up to date, instead of "Text note in english" and "text note in Korean."

What we decided on, was Revits Keynotes. Typically meant to show either a Numeric Tag, or the text of a note, we elected to have it show both.... The number, and the tag of the note. Except, we also elected to not have it show a number, but show the English version of the note AS the number, and the Korean version of the note as the Text. So, just as normal in Revit, we made our Keynote file. (Note: We had to save it as Unicode Encoding again, or it didnt work...).

Once the keynote file was created, it was business as usual in Revit. We made three types of Keynote tags. For each language, and both language. Depending on what we want to print.












The only difficult part is having the Project Team know which note was which, since they cant get sorted alphanumerically, given that weve "replaced" the Keynote Number with an actual text field. Along this front, i think it would be great if we could add additional fields to Keynotes and Keynote schedules. We already do something similar when we add parameters and Shared Parameters to Type Catalogs.
The keynote file is nothing more than a Tab Delimited file, so i wonder why it can ONLY be "key number Keyed Note". The more we get in go complex models, and now (in the last few versions) with the advent of multi parameter labels, it seems like were begging for "Key NumberKey Note EnglishKey Note ForeignInstance Based Text Field," where Instance Based Text field is a note that applies TO the Keynote, but in this one location only. BIM-esque or not, its one of the small features Keynotes need that is a hang up for mainstream adoption.

Anyway, its not a perfect solution, and its not without effort. But this is how were crossing the multi-language bridge. How are you?





EDIT: I should add- Because of the users on Windows Vista, we DIDNT end up keeping it all Arial. We switched to Gulim, which is a native Windows font that supports korean Text. That way- even though the enoding was right- all of the project team could see it on the screens correctly. Unfortunately, when youre actually "IN" a Revit room schedule (not looking on sheet, but in it), they still display incorrectly, unless youre actively in the field. At which point, they display correctly. Strange!