The PointFire Blog - The PointFire Blog for Multilingual SharePoint #SharePoint 365The PointFire Blog - The PointFire Blog for Multilingual SharePoint #SharePoint 365https://blog.icefire.ca/blogs/tag/sharepoint-365Sun, 13 Jul 2025 12:09:53 -0700http://zoho.com/sites/<![CDATA[PointFire 365 will soon have a new look and new architecture]]>https://blog.icefire.ca/blogs/post/pointfire-365-will-soon-have-a-new-look-and-new-architecturePointFire 365 is getting a new look. This is part of our plan to consolidate the two apps, classic and modern, into a single app. Translate any SharePoint page in seconds]]>

You may have seen the message in the Message Center or in the App Catalog about the demise of SharePoint Add-ins in 2026.  The upcoming version 3.0 of PointFire 365 will retire its own add-in at the same time as it brings in the new look.


Currently, PointFire 365 has two apps, both of which must be added to the site, named PointFire 365 and PointFire 365 Modern.  In rough terms, PointFire 365 handles classic pages and pages in classic mode, while PointFire 365 handles modern pages.  To use Microsoft’s terminology, “PointFire 365” is an add-in and “PointFire 365 modern” is an app.  To avoid redundant code, the two apps (formally an app and an add-in) work hand in hand.

In recent years, SPFx has added a lot of functionality that it was missing, to the point that it is now possible to put all the functionality into a single app.  The project for doing this started long before the Microsoft announcement.


Another aspect of this new version is changing a lot of the popup and configuration page from full pages as they mostly are now, to panels on the right of the page, as you often see in modern apps and as you have doubtless seen while editing modern pages.  As it happens, doing popups and pages is something that is difficult to do in a modern app and we were planning to do away with those anyway.  Doing the architecture change and the UI change at the same time makes sense.


Version 2.7 of PointFire 365 is the last one where the classic app is mandatory.  Version 3.0 will still have both the classic and the modern app, but the classic app will not have much functionality other than helping with the transition for users who are used to the current apps.  This will happen this summer 2024, long before Microsoft’s 2026 deadline, so the impact on existing users will be minimal.

Download PointFire free trial
]]>Wed, 10 Apr 2024 09:44:31 -0400<![CDATA[Multilingual proofing of SharePoint pages]]>https://blog.icefire.ca/blogs/post/multilingual-proofing-of-sharepoint-pagesMicrosoft was rolled out Multilingual proofing for SharePoint. We take a deep dive into its capabilities and limitations.]]>

We saw in April 2022, when SharePoint introduced the Microsoft editor to the SharePoint page editing experience, that it was not able to detect the language of the text, so it would often fill the screen with red squiggles when there was a different language.  Luckily, by popular demand a few weeks later they rolled out a way to turn it off.  But as of a few weeks ago, language detection is here.  Multilingual proofing for SharePoint editing has been rolled out.


Now it is possible to have proofing in several languages at once, as you see in this picture



As you can see it correctly picked up typos in the English text, in the French text and in the German text, but it does not do the Portuguese text, it put squiggles under each of those words.

 

How did I configure it to get those results?  First let’s look at the announcement in the admin centre’s Message Centre.



It’s not much to go on, but further down it also says this: “The Microsoft Editor Spellchecker, now integrated in SharePoint pages, will now be able to proof text in multiple languages. In addition to supporting the Page language, Editor now proofs in the M365 language and the Edge browser language. Any word in any of these three languages, will be spell checked appropriately. ”


What are these three languages?  It refers to the “Page language”.  The page language usually means the base language of the site, but if you have the multilingual page publishing feature activated, it can also mean the language of the copied page that is created for you to translate.  It also refers to “the M365 language”, and it is a bit mistaken about that.  What it actually means is the Office 365 profile language, which is not necessarily the same as the Microsoft 365 account language.  The other one is the “Edge browser language”.  Of course it doesn’t have to be Edge, all browsers have the ability to list the languages that you have configured the browser for.


Let’s test the feature.  First, I turned off Chrome’s own spell checking and confirmed which language the browser was configured for.  Edge and other browsers all have similar settings.



In this case I have configured Chrome for three versions of English, one version of French, and one version of German, so three languages altogether excluding the variants.  I also turned off the spell checking.


Next, I turned off the Microsoft Editor browser add-in, whose settings would supersede the simpler version of Microsoft Editor that is built into SharePoint. Lastly, I turned the Editor feature back on, which I had turned off when that setting had become available, by pressing on “Page details” and turning on the “Use Editor” setting.



Now it finds typos in English, French and German, but not in Portuguese.

Next, I added some Spanish text and then changed my Office 365 profile language to Spanish but not my Microsoft 365 account language.  


It then happily spell-checked the Spanish text.



Maybe the combination of Spanish and Portuguese isn’t the greatest example given that some words appear in both languages, but the perfectly correct Portuguese word “revisão” is not recognized.  When we click on the word to find spelling suggestions, it suggests words in English, Spanish, French, and German, notice the two-letter language codes, but not in Portuguese.


One thing that is interesting about this is that, based on the announcement, on similarities with the Microsoft Editor browser extension, and on sneaking a peek at the code, it theoretically should only support up to three languages.  In actual fact, it supports as many languages as I tried.  I did notice that when you have more than one language, it stops checking for grammar or syntax as well as it does with a single language.


This is a significant improvement in the editing experience for people with multilingual sites, so if you had turned off the Editor feature, now is the time to turn it back on.


I hope you found this article helpful. Feel free to leave me your questions in the comments.

You might also like


Localizing "group by" headers for choice columns using JSON view formatting in SharePoint Online


Language-dependent JSON column formatting, this time it's the IIlcid token

]]>Mon, 27 Mar 2023 11:54:56 -0400<![CDATA[Localizing "group by" headers for choice columns using JSON view formatting in SharePoint Online]]>https://blog.icefire.ca/blogs/post/localizing-group-by-headers-for-choice-columns-using-json-view-formattingIn previous posts, I’ve shown how Choice column values can be localized using a variety of techniques in JSON column formatting, most notably by using the “@UIlcid” token. Can these techniques also be used when doing “group by” these choice columns? Let's find out]]>

In previous posts, I’ve shown how Choice column values can be localized using a variety of techniques in JSON column formatting, most notably by using the “@UIlcid” token.


Can these techniques also be used when doing “group by” these choice columns?  The short answer is no.  But fear not, a design decision in SharePoint that normally breaks localization can be used to enable localization.


Let’s have a look at what happens when we see a list that is “grouped by” a choice column.  Here it is in English, grouped by “progress”:



We have applied the technique from the Language-dependent JSON column formatting blog post so that the choice column values are localized into French and German.  However as we can see below, this does not extend to the “group by” headers, those remain in English.  The column value, in blue, is localized, but the same value in the header is not.



The display of values in the columns can be customized by column formatting JSON, but display of values in the group-by headers must be customized by view formatting JSON.  Let’s have a look at how we can change that formatting.  In the View menu, we can find “Format current view” in the bottom.  In this case we are going to format the AllItems (default) list view.


By default it offers the graphical “design mode”.


Let’s select “Advanced mode” to see the JSON.  It is initially empty other than the schema declaration, so it uses some default formatting.



There are relatively few examples or information on what to do next, but we will add a minimalist formatting skeleton.  The syntax is described here https://learn.microsoft.com/en-us/sharepoint/dev/declarative-customization/view-group-formatting

The “group by” headers are within “headerFormatter” within “groupProps”.



The syntax for “headerFormatter” is identical to that of column format, with the important caveat that a lot of it, despite correct syntax, does not work.  Yes, there is a “txtContent”, but things like “@currentField” and “[$FieldName]” are not defined and most special strings, most notably "@UIlcid", are not available.


That makes determining the language and formatting the value depending on the language difficult, because all of the techniques discussed in previous posts are not available.


What is available is "@group", which has three properties,  "fieldData", "columnDisplayName", and "count".  Normally the use of column display names rather than internal names is a mistake.  If you rely on it then things will break badly (like they do for list form JSON formatting) when you change the language, but in this case, that unfortunate design decision can be used to our advantage.


In this case we have already localized the column names by entering the translations in the MUI (Multilingual User Interface)  That means that the “Progress” column has a column display name of “Progress” in English, “Progrès” in French, and “Fortschritt” in German.  The value of “@group.columnDisplayName” therefore tells us what is the current UI language, as long as the column header has been localized and its name is different in different languages.


If we display the value of “@group.columnDisplayName” and of “@group.fieldData” in English we get this:



We see “Progress=New application” But in French we get “Progrès=New application”



The “columnDisplayName” is localized by the MUI, but the column value is not localized by our column formatting.  We can put this all together to take advantage of the display names.  In the nested ifs below, we check the value of “@group.columnDisplayName” to determine the current language, then the current value, and then display the appropriate translation of that value.



Here is the result, in French



And in German



What if the user decides to group by Position, a different Choice column, rather than by Progress?  There is only one view formatting JSON no matter what you group by, and only one “groupProps” and one “headerFormatter”.  Luckily the value of “group.columnDisplayName” detects not only the language but also which column is being grouped by, so you can just extend the nested ifs and localize all the choice columns from the view in a single “txtContent” expression.


The technique of using of “group.columnDisplayName” works for “@group” within the “group by” header as shown above, but it will also work for “@columnAggregate” in the footer and for the “@aggregates” array elements where applicable, and it also works for Gallery view.


Was this useful? Leave us your questions in the comments section below!

Related Posts

]]>Wed, 08 Mar 2023 11:47:08 -0500<![CDATA[Language-dependent JSON column formatting: this time it's the @UIlcid token]]>https://blog.icefire.ca/blogs/post/language-dependent-json-column-formatting-this-time-it-s-the-uilcid-tokenThis seems to have become a series, as Microsoft adds features to SharePoint JSON formatting.  The previous installment is here .  A week ago ]]>

This seems to have become a series, as Microsoft adds features to SharePoint JSON formatting.  The previous installment is here.  A week ago, Microsoft released a new @UIlcid token, which corrects the problem that I discussed in the previous post.  This time, this token is the actual current language of the site, unlike the @lcid token that was available before.

So unlike the earlier post (read it now) using "@UIlcid" rather than "@lcid" resolves all the issues about matching the Language and the Locale.  The example is very similar to the previous post, and the effect is the same, just use "@UIlcid" (Note: it's case-sensitive) rather than "@lcid" and you can replace the display of field values including choice columns with the translation without changing the value that is stored.


Does it apply to other places where the value appears?  Yes!  Well, most of the time.  Does it work in "new" and "edit" panes?  Yes!  Below, both the selected and unselected values are translated.


Does it work for "Type to filter"?  No.  The filtering mechanism knows nothing about the translations.  For that you would need to use multilingual managed metadata instead; it knows about translated values and can filter by them, and now column formatting works on that field type.


Does it work in grid view?  Yes it does!



Does it work with Multi-select choice fields?  No, but it could with a little extra effort.  You would simply have to use forEach and loopIndex to go through the values and translate them individually, selected or not.


As you may have guessed, automatically translating choice columns is an upcoming feature of PointFire 365, with lookup columns to follow.



Related Posts

]]>Fri, 26 Aug 2022 16:11:46 -0400<![CDATA[Language-dependent JSON column formatting using the @lcid token]]>https://blog.icefire.ca/blogs/post/language-dependent-json-column-formatting-using-the-lcid-token

This is an update to my earlier blog post “JSON for different text in different languages”, where JSON column formatting is used to display different text in different languages.  Please read that post before reading this one. 

Since that post was published, a new “@lcid” token has become available.  There is a sample here by theChrisKent, and he demonstrates it in a video here

 

The technique in the sample and the video sounds better than what I had described in my earlier post, doesn’t it?  Except for one very important thing:  the @lcid token does not match the user’s current language, or in technical terms the UI Culture.  The @lcid token is the current locale of the session, sometimes called the region setting, which is a very different thing.  It’s confusing because both the current Language and the current Locale use many of the same locale IDs, but the Language matches the language of user interface elements, while the locale only determines the formatting of dates, numbers, and currency.  Locale has 209 possible values, but Language only supports 50 of these.  The other 159 are not just other variants of the same language, they can be the same language but in a different jurisdiction with a different currency, the same language with different alphabets or alphabetical order, or other languages altogether.


The user’s  display Language, if it is set and matches one of the site’s alternate languages, always overrides the site’s base language, and the user can set any number of languages, letting an algorithm decide which one will be selected.  Users can choose whether to have their Locale preference override the default site locale, and if they do they can only select one locale.  The locale is independent of the language. You can set your language to Welsh and your locale to Urdu if you so wish.


Language is a reliable indicator of the user’s current language on the current site.  Locale is not.  Using the @lcid token will choose the wrong language more often than not.


Using the @lcid token only works if the Locale setting correctly reflects the current language.  This is where PointFire 365 comes in.  One of the lesser-known features of PointFire 365 is that it synchronizes the user’s locale with their language, and uses the user’s locale rather than the site locale.  This is mostly so that date, number, and currency formatting will be correct for the user’s current language.  Otherwise, you might get calendars with the names for months and days in the wrong language.  Because of this PointFire 365 feature, the @lcid token will actually match the page language.

 

So what does the use of the @lcid token in JSON column formatting look like in practice?  Here is a new version of the sample code snippet that was used in the earlier post:

Here, rather than checking the value of “Yes”, the JSON code is checking the value of @lcid.  The code is just for two values of the field, “New application” and “Active”, but you get the idea.  Here is what it looks like in English, French, and German.

The benefits of using this technique rather than the one in the earlier post are

  1. It is slightly shorter than before
  2. It does not require an additional Yes/No column in the view
  3. It can support all 50 SharePoint languages


The disadvantage (for some)

  • It will usually not work without PointFire 365


If you do not have PointFire 365, then the technique in the earlier post is better.

Related Posts

Localizing "group by" headers for choice columns using JSON view formatting in SharePoint Online

Language-dependent JSON column formatting using the @lcid token

JSON for different text in different languages

]]>Tue, 05 Jul 2022 11:34:48 -0400<![CDATA[How to Translate SharePoint Online's Content Type Gallery]]>https://blog.icefire.ca/blogs/post/translate-sharepoint-online-content-type-galleryHow do you localize content types and site columns in the content type gallery in SharePoint Online?]]>
How do you localize content types and site columns in the content type gallery in SharePoint Online? Most content types will inhering their  descriptions and column names from these higher-level content types, it's important to get them right in the first place.
If you go to the SharePoint admin center, for instance by going to "https://(tenantname)-admin.sharepoint.com/" you can expand the Content services menu item to get to the Content type gallery. By the way, see the Term store item there? Term stores are easily translated, but that's for another day.

To edit the content type gallery in SharePoint, select Content Type gallery.  

You can also get there directly using
https://(tenantname)-admin.sharepoint.com/_layouts/15/online/AdminHome.aspx#/contentTypes


It's easy to edit and to create content types from there, by clicking on "Create content type", see image below.



You are prompted for a name and description in only one language, even though name and description support MUI (Multilingual User Interface). There is no easy way to edit the content type's name and description and the names and descriptions of the columns used in the content type in languages other than your own.


To do that you have to go to the content type hub site, a hidden site, using the fixed URL "https://(tenantname).sharepoint.com/sites/contentTypeHub/"


All the content types are on this site. To see and edit all the content types, you go here: "https://(tenantname).sharepoint.com/sites/contentTypeHub/_layouts/15/mngctype.aspx"


You could change your language and then edit the name and the description of every content type, and within each content type you could change the name and description of every site column in that language. For the site columns you could also go to "https://(tenantname).sharepoint.com/sites/contentTypeHub/_layouts/15/mngfield.aspx" to edit the names and descriptions directly. If you have multiple languages, you can do that once for every language.




If you have a PointFire 365 license, a much easier way to do this is to install PointFire 365 on this hidden site, and activate it with all of the languages that you might use on any site in your tenant. Then within the PointFire 365, select "Translate the Interface". This will find every untranslated name and description of every content type and site column, suggest translations for your review, and apply them to the content type gallery.



It's a good idea to do this early on, before the content types get used on sites, so that the translated versions of content types can be available to every site, rather than having to break inheritance and translate them on each site individually.  Isn't it automatically applied to content types when you change it in the content type hub?  Isn't that the point of a content type hub?

Be careful about inheritance of the translation of site columns and content types. SharePoint does not always propagate changes made only to a translation unless some other property of the columns or content type itself has changed. You need to make a change other than translation to the column or content type in order to initiate a re-publishing.

]]>Wed, 04 Aug 2021 17:58:46 -0400<![CDATA[New languages in PointFire Translator]]>https://blog.icefire.ca/blogs/post/a-few-new-languages

Because of recent changes to the Azure Translator Text API, a few new languages in the Western Iranian language group are being added to PointFire Translator.

Two versions of Kurdish are being introduced, Kurdish (Central), language code "ku", also called Sorani, and Kurdish (Northern), language code "kmr", also called Kurmanji.

In addition, two languages of Afghanistan are being added. Dari (prs) and Pashto (ps).  PointFire Translator had already supported Dari and Persian, and Dari is also supported by PointFire 365 and SharePoint. However, we had been using the same language code and translation engine for both of them, because they are so similar. Now Dari will use "prs" and Persian will use "fa" for Farsi, another name for the same language.
]]>Fri, 21 Aug 2020 16:08:00 -0400<![CDATA[I Know What Im Doing, But...]]>https://blog.icefire.ca/blogs/post/translate-sharepoint-online-s-content-type-gallery1How do you localize content types and site columns in the content type gallery in SharePoint Online?]]>

My review of the Collab365 Microjobs

One of my colleagues suggested to me that I should try Collab365’s MicroJobs and then write a review about it.  I subscribe to some Collab365 mailing lists, they have daily summaries of all the important news and blogs, and they organize some great conferences.  It’s one of the few automated emails from outside my company that I read carefully every day, motivated by FOMO.

The newsletters and the site mention MicroJobs all the time and I keep thinking that sounds like a good idea but it’s not for me.  But my colleague insisted I should do it and Fraser Beadle of MicroJobs joined her in gently coaxing me to try it.

I’ve been working in the SharePoint and Office 365 space for over 10 years.  I run a SharePoint product company with all sorts of SharePoint experts working for us, I give talks at conferences, I write blogs, I Know What I’m Doing.  Any issue that comes up I can just search for some blogs and follow the instructions.  I don’t need hand-holding.

And yet when I tried to think of current nagging problems that might be solved in 30 minutes, I could think of several of them.  I couldn’t decide which one to try, so I signed up for two of them, very different types of problems.  In both cases the format was a 30 minute Expert Call.  MicroJobs offers a whole range of other formats, and a lot of fixed-price deliverables, for in all sorts of Microsoft areas, but for me the short Expert Call format was what suited me best.

Can the problems really be solved in 30 minutes?  If not, the site has a useful feature, “Custom extra” where I can ask for more time if required.  Bad news for them, good news for me, in both cases the experts solved my problems in a few minutes, walked me carefully through the solution, and then had time left over within the 30 minutes to solve a second problem.

The first problem I had was for an internal SharePoint site, used by our company's Marketing and Sales staff, with one list in particular where they wanted to change the order of the columns in the New and Edit forms, and to hide some columns.  I don’t think it’s a good use of company resources to use our developers’ time or our client support staff to do this sort of thing for our marketing and sales staff, which would mean they have less time for our customers.  Typically Sales & Marketing fend for themselves or I do it for them myself.

I had tried to do it myself.  There were complications and the usual way to do it didn’t work.  Sometimes they use Modern view and sometimes they use Classic, so that limits how it can be done and there were issues with content types and site columns.

I could have researched it myself and spent a lot of time reading blogs, found solutions for slightly different problems that may or may not apply to me, or looked up some relevant conference slides or a YouTube video.  But why do that when someone who wrote the blog or gave the conference talk or recorded the video is probably on MicroJobs and willing to do this for me?

In this case an experienced MVP was willing to do this for less than what I would pay a taxi driver for the same amount of their time.  I don’t know why they do it.  When I was a freelance consultant, I charged a lot more than that and I wouldn’t have agreed to do 30-minute assignments, not worth the overhead.  Take advantage of it before they realize they should charge more!

I headed to jobs.collab365.community and gave it a shot.

The MicroJobs site is easy to use.  I use other freelancer sites for other things, and this one is easier, and the level of experience of the freelancers on the site is noticeably high.  Log in using a Microsoft account, or LinkedIn, or Google, or Facebook, or an email.  Then search for what you’re looking for.  You’ll see offers that some of the experts have posted.  You can also post a request and have people offer to help you, or you can find the right person first and ask them whether they could do the task that you need done.

I contacted Nick through the site, which has a handy chat interface.  We discussed it a bit, then set a time, and later on we changed that time a bit.  The MicroJobs site has a built-in videoconferencing and screen sharing tool (based on Jitsi Meet it looks like) that works really well right in the browser, and lets you talk and share your screen.

I shared my screen and Nick understood right away what I wanted to do, a list of about 10 changes.  It had to be done in classic mode.  We ran into a couple of small difficulties, which reassured me that the problem was not obvious, and they were solved right away.  I’m not particularly fast in doing the "click there", "type this", and yet we were done in 15 minutes. Pro tip: have a second problem ready.  OK, I said, if there is more time here is something else I was planning to do: add a new content type to the list, with a subset of the columns and the ability to promote a record from one content type to the other.  That turned out to be a bit more difficult.  None of the columns were site columns but this would have to be a site content type.  No problem.  Nick guided me in creating a site content type that inherits from the same parent as the other, then modifying its instance within the list.  He reassured me that we could omit a required column.  Within a few minutes we were all done and had 5 minutes left to test that it worked for new and edit forms in both classic and modern mode, and that we could promote an item to a different content type.

Verdict, on a tricky problem that I couldn’t figure out, we got twice as much done as I expected, and I had to compromise on nothing.  The payment gateway released the money when he and I agreed that the work was completed.  After it was all settled, the invoice came straight from the expert, not the site.

The second problem was one that had to do directly with one of our products, so I am being be less specific as to the details.  For our machine translation product for modern pages, we provide instructions as to how to call it from a Power Automate flow so that a page can be translated as soon as it’s published.  But I wasn’t sure whether the instructions we planned to provide would follow best practice in terms of security and good governance.  Through the MicroJobs site I found Matthew, an expert in Power Automate, another MVP, who also knew a lot about Azure app registration including the less common authentication method that we were using.

Chatting with Matthew prior to giving him the task, he seemed to understand quickly and he asked me whether I knew about a different feature of Power Automate, and said we should have a chat about it.  I knew a bit about that other feature and I didn’t think it applied to this. I dismissed the suggestion.  I didn’t want to change the software, I just wanted best practices for deployment.  Perhaps we could look at that other feature later if there is time.

Matthew accepted the job, he set it up with Teams and we started the call at the appointed time.  He started out saying "I just want to show you this feature, I think it will help you."  OK, I thought, let’s have a look at it for a few minutes and see why he’s so keen on it.  It turns out it was exactly what we needed.  We didn’t have to explain away the security issues, this just solved them and we didn’t have to change a single line of code.  It was also a lot more flexible and scalable.  This is way beyond my expectations.  This is why it’s useful to speak with experts, they don’t just answer your question, they solve the underlying problem, and combine their knowledge and experience to analyze it and to think of the best way to solve it.  I would never have thought of this by just Googling answers to my how-to questions.  We started implementing his advice right away.

Just before the part where he was showing a sequence of steps with a detailed example, Matthew asked whether he could record the part of the session so he could send it to me.  Very thoughtful, I can use it for later reference if I forget some of the steps.

This MicroJob had a significant impact at very little cost.  This is definitely something I would do again.

You get to rate the freelancer.  These ratings are made public.  The freelancer also gets to rate you.  That is not public as far as I know, but might be available to other freelancers.  Apparently I’m “laid back” and “easy to work with”.  Nice to know.

But what happens if things do not go as well?  Thanks to my mistakes I got a tour of the dispute resolution and order cancellation process.  Apparently, I ordered the same MicroJob twice.  Not only that, but I marked it as delivered  twice, I convinced the consultant to mark the second one as delivered, thinking that he had forgotten and it was the same job, and I even paid for it twice.


I don’t think anyone had ever done all of that before, so when I contacted the freelancer to cancel it after realizing my mistake, he wasn’t certain how to fix this, and tried the dispute resolution mechanism. 

The dispute resolution mechanism is nicely thought out and goes to the dispute resolution team.  In this case, they apparently thought there was a better way to handle this.  They cancelled the dispute to reinstate the job and then the freelancer initiated a cancellation by mutual consent. 

Cancellation by mutual consent is very straightforward.

I received an email, followed the link to the site, and consented to the cancellation.  The money was immediately refunded to my credit card. 

The final verdict is that the process is well thought out, the people and service are high quality, it is a bargain, and it is essentially risk free.  Some day they will figure out that they could be charging higher rates, but for the time being take advantage of it.

Disclaimer:  I am not being paid for this review, but the people at Collab365 encouraged me to try it and to review it.  They offered to reimburse me for my first MicroJob but I declined.


You can watch my video review on youtube.

]]>Fri, 31 Jul 2020 03:07:00 -0400<![CDATA[Why Do We Need PointFire for Multilingual Collaboration in SharePoint? Part I]]>https://blog.icefire.ca/blogs/post/why-do-we-need-pointfire-for-multilingual-collaboration-in-sharepoint-part-i
While SharePoint does provide certain multilingual features, we find that our clients require a little more flexibility and responsiveness in the multilingual user interface and content delivery as well as a simplified method to manage multilingual content and documents. PointFire provides this solution as well as providing many other useful tools for customizing the look and behavior of your SharePoint sites.
 

Here is Part I of this series that will cover the reasons you need PointFire in a multilingual SharePoint environment.

Translation Control

If you look at the list of elements that the SharePoint MUI doesn't support, PointFire supports all of the rest, with very few exceptions (some aspects of Silverlight and InfoPath, for which we provide workarounds). You can see a few specific scenarios in the first few pages of the PointFire 2010 User GuideGuide http://community.icefire.ca/index.php?/Knowledgebase/Article/View/97/9/pointfire-2010-user-guide
 
First and foremost: content.  PointFire does not only handle the "chrome" but user-generated content as well.  It reaches inside html pages and inside lists and libraries to translate what you want it to translate.  It intercepts ajax calls, RSS feeds, and some Javascript to translate as appropriate.  Here is a partial list of elements that PointFire does and the SharePoint MUI doesn't
 

webpart titles and properties

custom webparts

templates that MUI doesn't support, such as blogs and workspaces

custom properties

custom additions to various menus & ribbons

search refiners

permission types

group names

multi-valued columns values

calculated text fields

ajax

embedded xml

embedded javascript

alert & popup messages

dialogue boxes

custom new/edit/ etc forms

questionnaires

views

folder names

    In addition, it does some translations with less effort than the MUI in many cases.  For instance, if you add a custom list and put it in the quick-launch menu, then provide the translation of the list name, the translated list name will not appear in the menu unless you edit it separately.  With PointFire, you only have to add the translation in one place.   In fact, if the same list name is used elsewhere in a different site, PointFire can inherit that translation from another site.
     

    Of course, translation is only one of the 4 localization techniques that PointFire makes available.  There are much more powerful filtering techniques that allow you to tag content in lists, libraries, pages, and webparts as being in one language or the other, allowing SharePoint to assemble the page in the user's language while using the same URL.

    ]]>    Sun, 14 Jul 2013 22:59:00 -0400