I'm generating some vCards for employees in my company which will be served over the web. Most of the individuals are licensed professionals. I would like to include their accreditation, associations, license numbers, etc... in their vCards.
I've been using RFC6350 and its examples as a guide. There is a specific example in sec 6.2.2 that pretty much what I want. According to the RFC's special note, the 4th and 5th elements should contain honorific prefix and suffix. I'm not sure my desired usage fits this description, however in their example, it is used in this way.
Example from RFC: N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.
The problem I'm having:
When the vCard is imported into Outlook, Outlook seems to parse the N: field to populate its internal fields:
N:{last name};{first name};{middle names};{prefix};{suffix}
When I look at the contact properties the suffix is actually being stored as the "Generation" Property.
After saving the vCard, Outlook seems to calculate the "Display as" property by combining {first name} {middle name} {last name} {generation}, which potentially creates excessively long "display as" names. So, using the RFC's example, Outlook will generate an email addressed to "John Philip,Paul Stevenson Jr.,M.D.,A.C.P. (test#example.com)" <test#example.com>. In my case: "Example User, AIA, NCARB, SEI, LEED GREEN ASSOCIATE(test#example.com)" <test#example.com>
My question is: Is there a more appropriate vCard field to store credentials that I am missing, which will not pollute Outlook's display as field OR is there a way to supply a custom "Display as" property in the .vcf that Outlook will pick up on?
I'm testing in Outlook 2016
Related
I have task to export Activities including 'Descriptions' filed which contains HTML of the stored email treads. I have to export this field/column as parsed text (not HTML codes, only a real content of the mails).
Actually, when Activities listing is displayed in web, Descriptions column displays exactly what I need, but when I export it to excel, this columns displays HTML codes (and is limited to 1044 chars, so there is no any real body content).
Please, give some advice or link where I can learn how to export this field as it looks in web.
Thanks.
Unfortunately, plain text email body is not stored automatically by OOB CRM. All you have is Rich text stored description field.
There are multiple different solutions to strip the HTML tags & store the plain text in a different field viz code solution, no-code configuration solution using third party like North52, etc.
If you have developers in your team, then C# Plugin would be the best bet to strip & store on creation of Email record itself.
Would a Report Wizard report work to give you the results you need?
Also, Arun's answer was marked as correct (as it should be...) My only advice would be to store the email body without the HTML tags in a different field. I've found that stripped HTML tags can do funny things to formatting.
When a batch gets created documents should get separated automatically without using separator sheet or Barcode separator.
How can I classify documents for Invoice and supporting document.
In our project we get many invoices with supporting document so the scanning person has to insert the separator sheets manually, so to avoid this we want to automatically classify the supporting documents.
In general the concept would be that you would enable separation in the project and then train your classes with examples to be used for the layout or content classifiers.
However, as I'm sure you've seen, the obstacle with invoices is that they are different enough between vendors that it would not reliably classify all to an Invoice class. Similarly with "Supporting Documents" which are likely to be very different from each other, so unfortunately there isn't a completely easy answer without separator sheets (or barcode stickers affixed to supporting docs).
What you might want to do is write code in the one of the separation events like Document_AfterSeparate event. Despite the name, the document has not yet been split at this point, but the classifiers have run. See Scripting Help topic "Server Script Events Sequence > Document Separation > Standard Document Separation" for more detail. Setting the SplitPage property on the CDocPage (pXDoc.CDoc.Pages.ItemByIndex(lPage).SplitPage) will allow you to use your own logic to determine which pages to separate.
For example if you know that you will always have single page invoices, you can split on the first page and classify accordingly. Or you can try to search for something that indicates the end of the invoice like "Total" or other characteristics. There is an example of how you can use locators to help separation in the Scripting Help topic "Script Samples > Use Locator Results for Standard Document Separation". The example uses a Barcode Locator, but the same concept works if you wanted to try it with a Format Locator or anything else.
Without Separator sheets you will need a smart classification software like Kofax Transformation Module (KTM). Its kind of expensive. you will need to verify the cost saving and ROI.
I have outlook 2011 in my mac. I have more than 30,000 emails in my mail box and would like to search from all the mails based on inputs.
Now using Advanced find I can do that , But for each and every value I have to add a new search criteria
eg . Subject contains xxx
Subject contains yyy
Subject contains zzz
it would be very difficult for me to add the search value manually if I have 1000 values to search for.
Is there any effective way to do this or do we some plugin which would read from input file and populate these vales ?
Any help would be really appreciated
I think, you can get little bit help from this -- http://derflounder.wordpress.com/2011/04/26/finding-the-hidden-search-options-in-outlook-2011/ , also this one too - https://www.gvsu.edu/cms3/assets/428A2C9A-0FB7-5B0C-BBFCF723C12E59E3/outlook_mac_search_email.pdf
In Windows version of Outlook there is a hidden tab that can be enabled by creating a new registry key HKEY_CURRENT_USER\Software \Microsoft\Office\12.0\Outlook\QueryBuilder. See here (sroll to Building DASL Queries).
This adds SQL tab to Filter dialog of Customize Current View. Here you can write a text with DASL query. The query for your example would look like this:
("urn:schemas:httpmail:subject" LIKE '%xxx%' AND
"urn:schemas:httpmail:subject" LIKE '%yyy%' AND
"urn:schemas:httpmail:subject" LIKE '%zzz%')
You can create script that takes all keywords from a text file and formats them like
"urn:schemas:httpmail:subject" LIKE '%MyKeyword%'
and construct the DASL query prorgamatically from a text file. You can store your generated queries as text files and copy them in the SQL tab as necessary.
This solution is surely far from perfect but it is relatively easy to implement. The problem is that I do not know how to enable that tab in Outlook 2011 on Mac nor whether it is possible at all. I do not have a Mac so take this rather as a hint.
We do have a website which should be translate into different languages. Some of the wording is in message properties files ready for translation. I want now add the rest of the text into these files.
What is a good way to name the text blocks?
<view>.<type>.<name>
We mostly have webpages and some of the elements/modules are repeating on some sites.
As far as I know, no "standard" exists. Therefore it is pretty hard to tell what is proper and what is improper way of naming resource keys. However, based on my experience, I could recommend this way:
property file name: <module>.properties
resource keys: <view or dialog>[.<sub-context>].<control-type>.<name>
We may discuss if it is proper way to put every strings from one module into one property files - probably it could be right if updates doesn't happen often and there are not so many messages. Otherwise you might think about one file per view.
As for key naming strategy: it is important for the Translator (sounds like film with honorable governor Arnold S. isn't it?) to have a Context. Translation may actually depend on it, i.e. in Polish you would translate a message in a different way if it is page/dialog/whatever title and in totally different way if it is text on a button.
One example of such resource key could be:
preferences.password_area.label.username=User name
It gives enough hints to the Translator about what it actually is, which could result in correct translation...
We have come up with the following key naming convention (Java, btw) using dot notation and camel case:
Label Keys (form labels, page/form/app titles, etc...i.e., not full sentences; used in multiple UI locations):
If the label represents a Java field (i.e., a form field) and matches the form label: label.nameOfField
Else: label.sameAsValue
Examples:
label.firstName = First Name
label.lastName = Last Name
label.applicationTitle = Application Title
label.editADocument = Edit a Document
Content Keys:
projectName.uiPath.messageOrContentType.n.*
Where:
projectName is the short name of the project (or a derived name from the Java package)
uiPath is the UI navigation path to the content key
messageOrContentType (e.g., added, deleted, updated, info, warning, error, title, content, etc.) should be added based on the type of content. Example messages: (1) The page has been updated. (2) There was an error processing your request.
n.* handles the following cases: When there are multiple content areas on a single page (e.g., when the content is separated by, an image, etc), when content is in multiple paragraphs or when content is in an (un)ordered list - a numeric identifier should be appended. Example: ...content.1, ...content.2
When there are multiple content areas on a page and one or more need to be further broken up (based on the HTML example above), a secondary numeric identifier may be appended to the key. Example: ...content.1.1, ...content.1.2
Examples:
training.mySetup.myInfo.content.1 = This is the first sentence of content 1. This is the second sentence of content 1. This content will be surrounded by paragraph tags.
training.mySetup.myInfo.content.2 = This is the first sentence of content 2. This is the second sentence of content 2. This content will also be surrounded by paragraph tags.
training.mySetup.myInfo.title = My Information
training.mySetup.myInfo.updated = Your personal information has been updated.
Advantages / Disadvantages:
+ Label keys can easily be reused; location is irrelevant.
+ For content keys that are not reused, locating the page on the UI will be simple and logical.
- It may not be clear to translators where label keys reside on the UI. This may be a non-issue for translators who do not navigate the pages, but may still be an issue for developers.
- If content keys must be used in more than one location on the UI (which is highly likely), the key name choice will not make sense in the other location(s). In our case, management is not concerned with a duplication of values for content areas, so we will be using different keys (to demonstrate the location on the UI) in this case.
Feedback on this convention - especially feedback that will improve it - would be much appreciated since we are currently revamping our resource bundles! :)
I'd propose the below convention
functionalcontext.subcontext.key
logicalcontext.subcontext.key
This way you can logically group all the common messages in a super context (id in the below example). There are few things that aren't specific to any functional context (like lastName etc) which you can group into logical-context.
order.id=Order Id
order.submission.submit=Submit Order
name.last=Last Name
the method that I have personally used and that I've liked more so far is using sentence to localisee as the key. For example: (pls replace T with the right syntax dependably on the language)
for example:
print(T("Hello world"))
in this case T will search for a key "Hello world". If it is not found then the key is returned, otherwise the value of the key.
In this way, you do not need to edit the message (in your default language) at least that you need to use parameters.... It saved me a LOT of dev time
I am in the middle of designing a web form for German and French users. Within this form, the users would have to type street names several times.
I want to minimize the annoyance to the user, and offer autocomplete feature based on common French and German street names.
Any idea where I can a royalty-free list?
Would your users have to type the same street name multiple times? Because you could easily prevent this by coding something that prefilled the fields.
Another option could be to use your user database as a resource. Query it for all the available street names entered by your existing users and use that to generate suggestions.
Of course this would only work if you have a considerable number of users.
[EDIT] You could have a look at OpenStreetMap with their Planet.osm dumbs (or have a look here for a dump containing data for just Europe). That is basically the OSM database with all the map information they have, including street names. It's all in an XML format and streets seem to be stored as Ways. There are tools (i.e. Osmosis) to extract the data and put it into a database, or you could write something to plough through the data and filter out the street names for your database.
Start with http://en.wikipedia.org/wiki/Category:Streets_in_Germany and http://en.wikipedia.org/wiki/Category:Streets_in_France. You may want to verify the Wikipedia copyright isn't more protective than would be suitable for your needs.
Edit (merged from my own comment): Of course, to answer the "programmatically" part of your question: figure out how to spider and scrape those Wikipedia category pages. The polite thing to do would be to cache it, rather than hitting it every time you need to get the street list; refreshing once every month or so should be sufficient, since the information is unlikely to change significantly.
You could start by pulling names via Google API (just find e.g. lat/long outer bounds - of Paris and go to the center) - but since Google limits API use, it would probably take very long to do it.
I had once contacted City of Bratislava about the street names list and they sent it to me as XLS. Maybe you could try doing that for your preferred cities.
I like Tom van Enckevort's suggestion, but I would be a little more specific that just looking inside the Planet.osm links, because most of them require the usage of some tool to deal with the supported formats (pbf, osm xml etc)
In fact, take a look at the following link
http://download.gisgraphy.com/openstreetmap/
The files there are all in .txt format and if it's only the street names that you want to use, just extract the second field (name) and you are done.
As an fyi, I didn't have any use for the French files in my project, but mining the German files resulted (after normalization) in a little more than 380K unique entries (~6 MB in size)
#dusoft might be onto something - maybe someone at a government level can help? I don't think that a simple list of street names cannot be copyrighted, nor any royalties be charged. If that is the case, maybe you could even scrape some mapping data from something like a TomTom?
The "Deutsche Post" offers a list with all street names in Germany:
http://www.deutschepost.de/dpag?xmlFile=link1015590_3877
They don't mention the price, but I reckon it's not for free.