Babak Mahmoudi’s Blog

Localization for Persian Language…

Archive for December 2008

Localization of MOSS Built-In Workflows

with one comment

MOSS comes with a number of built-in workflows, such as Approval, Collect Signature and Feedback. It seems that standard language template packs, like that of Arabic language does not support these workflows. The challenge of localizing these workflows is actually that of translating the associated InfoPath forms. In this post I’ll discuss it in detail.

 Research and Findings:

XSN files are actually CAB files, one may open and edit and then recab them.

 Generic workflows, like Translation Management are implemented in Microsoft.Office.Workflow.Pages They have a code behind page to IniWrkflIP.ASPX with an onload method that actually computes the form and requests it from form server. The localization occurs here where a $Subst:LCID in the form urn name will be replaced with the actual LCID.

internal static
string GetLocalizedFormUrn (string
formUrn,
SPWeb
web)

{
     return formUrn.Replace(“$Subst:LCID;”, web.Language.ToString(CultureInfo.InvariantCulture));
}
Problem with “the form is not workflow enabled”
I did everything I could for preparing a Persian version off the forms. But when I installed these forms, I still had problem. SharePoint reported a “the form is not workflow enabled” error. Actually the form templates on Centeral Administration has a Workflow column which indicated “No” for my forms. Now I know that my forms should be installed with the feature to get enabled. So I did reinstalled the workflow feature. It just seems that any form in the feature directory will get installed this way.
We don’t know how’s that the original form templates are not “PUBLISHED” the way we should “publish” our forms to a sharepoint site prior to installing them on the form server. When we publish our forms the form will be marked for being published on our servers and we don’t know how they will be published on client urls:

The XSN has a tag with PublishURL on it, u omit this and form sever will assume that the form is correctly published.
<xsf:xDocumentClass solutionVersion=”12.0.0.6″ productVersion=”12.0.0″ solutionFormatVersion=”2.0.0.0″ name=”urn:schemas-microsoft-com:office:infopath:ReviewRouting-Assoc-1065-Edit:-myXSD” publishUrl=”C:\MyProjects\FarsiMOSS\GenericWorkflows\Review\Assoc\ReviewRouting_Assoc_1065_Edit.xsn” xmlns:xsf=”http://schemas.microsoft.com/office/infopath/2003/solutionDefinition&#8221; xmlns:msxsl=”urn:schemas-microsoft-com:xslt” xmlns:xdUtil=”http://schemas.microsoft.com/office/infopath/2003/xslt/Util&#8221; xmlns:xdXDocument=”http://schemas.microsoft.com/office/infopath/2003/xslt/xDocument&#8221; xmlns:xdMath=”http://schemas.microsoft.com/office/infopath/2003/xslt/Math&#8221; xmlns:xdDate=”http://schemas.microsoft.com/office/infopath/2003/xslt/Date&#8221; xmlns:my=”http://schemas.microsoft.com/office/infopath/2003/myXSD&#8221; xmlns:xd=”http://schemas.microsoft.com/office/infopath/2003&#8243; xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221; xmlns:xhtml=”http://www.w3.org/1999/xhtml&#8221; xmlns:aml=”http://schemas.microsoft.com/aml/2001/core&#8221; xmlns:dt=”uuid:C2F
Finally these are the flowing steps to translate a generic workflow form:

  • Get a copy of the form. It is in Features directory. For example for Review_Assoc:
    C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\ReviewWorkflows\Forms\ReviewRouting_Assoc_1033.XSN
  • Do the translation with InfoPath Save the file for 1065. For our example it would be ReviewRouting_Assoc_1065.XSN
  • Set the locale of the form on Persian if u like. This has no effect other than on Manage Form Templates if Centeral Administrator u’ll get correct form locale. But whatever locale u said, SharePoint is actually using te Form ID which should be corrected for 1065 (see below)
  • After completing the translation. Rename it with .Cab extension. Didn’t u know that? Inforpath forms are actually Cabinet compressed files.
  • You’ll find a MANIFEST.XSF file in the cabinet. Open it with note pad and edit it:
    • At the top of the file u’ll find a xsf:xDocumentClass tag. Within it u’ll get a name attribute. It should be corrected for the correct form name. Remember that when u edited the form template, InfoPath had automatically changed the form name here. It should be identical to that of english form name, just 1033 should be changed to 1065. For our example it would be:
      name=”urn:schemas-microsoft-com:office:infopath:workflow:ReviewRouting-Assoc:1065″
       
    • Just next to it u’ll find a publishURL attribute. Remove the attribute, i.e. delete it totally.

       
       

  • You should then Edit the Template.XML file. This file also contains a solution name that should be identical to the form name you set in the previous step. At the top of file, u’ll find a ?mso-infoPathSolution tag. Set the name attribute. For our example it would be:
    name=”urn:schemas-microsoft-com:office:infopath:workflow:ReviewRouting-Assoc:1065″
  • Now recab the form. U may use:
    Cabarc n ReviewRouting_Assoc_1065.XSN *.*
  • Copy the form to the soultion folder, where you picked the original 1033 version.
  • Now the feature should be reinstalled, so that the forms be installed with the feature. One may use STSADM to do that:stsadm -o deactivatefeature -name reviewworkflows -force -url http://babakserver 
    stsadm -o uninstallfeature -name reviewworkflows -force
    stsadm -o installfeature -name reviewworkflows
    stsadm -o activatefeature -name reviewworkflows -url http://babakserver

     

  • Sometimes it will be required so that you should Deactivate and re Activate the feature from Site Collection Features page.
  • To check if everything is ok go to SharePoint Central Administration \ Application Management\ Manage Form Templates. You should see somehing like this:
  • Note that the form should be Workflow Enabled.
  • Click on the 1065 version and use the View Properties option. You should see something like this:


  • Specially see the Form ID it should be exactly like what is shown here. Otherwise the form won’t be found.
  • Use the procedure for all forms in the workflow.

Now maybe you can see something like this:


 

Links:

http://www.gn.co.ir/KB/SharePoint/Lists/Posts/Post.aspx?ID=38

Written by Babak Mahmoudi

December 23, 2008 at 8:19 am

Posted in SharePoint

Tagged with ,

Morphological Rules Pertaining to Persian Spell Checking

with 12 comments

Preface
“Analyzing Persian texts as some stemmer algorithms is essential for efficient spell checking because: It provides the level of consistency needed and It may work with a concise lexicon.
In this article the morphological rules pertaining to such algorithms are studied.”
 Introduction
In Persian words are extensively combined with various prefixes and suffixes, to make new words. In this sense, and if we define words digitally as strings of characters surrounded by space, the number of Persian words are enormously larger as compared to Latin languages as English. For example the word كتاب (ketab=book) generates following derivatives:

ketab_ha books
ketab_am my book, I am a book 
ketab_at your book 
ketab_ash his book 
ketab_eman our book 
ketab_eshan their book 
ketab_i a book, you are a book, related to books
ketab_im we are books 
ketab_id you are books 
ketab_and they are books 
ketab_itar more related to books 
ketab_itarin most related to books 
ketab_hayam my books 
ketab_hayat your books 
ketab_hayash his/her books
ketab_hayeman our books
ketab_hayetan your books
ketab_hayeshan their books
ketab_haei some books
   
*the suffixes are presented just as they spelled in Persian.

 As seen in this example 19 different words can be made by the simple root “ketab”.

 The term Morphological Rules then refers to such rules in Persian that specify how new words can be made. It should be noted here that, by making words, we do not mean the process of generating totally new words as it is usually meant in Persian literature. Actually no one talks about ‘ketab_ha’ as a new word made from ‘ketab’. This is because our digital definition of word: “a string of letters separated by space”
Thus, here we are confined rather to those simple and certain rules that are thought to be useful in the process of digital proofing.

The term curtain is important because, we are not going to consider about those patterns that are rarely used. We consider those rules that can be applied almost in all cases. Nevertheless, the rules are applicable to words based on their grammatical natures. For example you cannot pluralize a pronoun, or only verbs can be conjugated.

Thus, it should be assumed that the Morphological Rules studied here are supported by some Lexicon in which Morphemes are stored with flags that designate their grammatical nature as pertaining to stated rules. The terms Flag, and Morpheme in this article refers to such Lexicon…

Find the remaining on the following link.

Download Complete Document

Written by Babak Mahmoudi

December 8, 2008 at 2:38 pm

Posted in Persian Language

SharePoint Pack

leave a comment »

In this post I’ll introduce the SharePoint Pack Project. This is a project defined in Gostareh Negar (www.gn.co.ir) to develop a pack of useful SharePoint tools.

Project Statement:

SharePoint Pack is defined to provide a pack of SharePoint tools and utilities in a usable form. The tools and utilities are often share-ware available. The main effort is to gather these items in a usable format, e.g. providing samples, guidelines, installation helpers and so on. Therefore in general less effort would be put on the developing the items.

 
 

Position and evidence of needs:

There are many useful items here and there, for SharePoint. But these are less available in production lines. When one decides to use them, s/he should start from searching web, put time to select a suitable solution, then try to install and test it. The output of this project can help the end-users to save time in using a set of tested items together with the required documentation.

 
 

Scope Statement:

List of potential workproducts:

  1. Workflow activities
  2. Web Parts
  3. Field Types
  4. List Templates
  5. Site Templates

     
     

    As said above the main focus will be on wrapping the existing items and providing help. Therefore following requirements should be checked for work products:

  6. Less development effort. In general the required time of a potential item should be less than a week. Normally we should start with an existing code. If an item goes beyond this time limitation, most likely it wont be covered in the scope of SP Pack.
  7. Each work product should have a neat and simple documentation providing following information:
    1. Why to use: The information about why the product is required and in which cases it can be used.
    2. How to use: The information about how the item can be actually used together with samples.
    3. When to use: Information about limitations and possible problems.
    4. Technical Information : Technical backgrounds, issues and sources.

Written by Babak Mahmoudi

December 8, 2008 at 2:13 pm

Posted in SharePoint