When using the Multilingual App Toolkit (MAT) v4, refactoring a string ID in a reference to a resx string will, as expected, change the ID of that string in all resx files. However, the xlf files are not touched, and when you recompile, MAT will 1) detect the refactored ID as a new string resource, and 2) remove the "old" string resource since it's no longer present in the master resx file.
Is it possible to properly (automatically) refactor string keys when using MAT?
The Multilingual App Toolkit does not support refactoring IDs. The resource ID (and source file) is used as the only unique identifier. Using the source string alone is not considered a reliable identifier alone
the XLF files are updated during the build operation, which is why you see the new/deleted string(s) after the build.
As a workaround, after the build you can import the previous XLF files with the recycling option enabled (Check box on the bottom of the Import UI). The recycling option uses the source string (and other check) to match refactor resources. (Of course, you will need to have a copy in source control or else were to set the previous values)
Related
I am using sensenet and react based client for front end. while copying a file from one document library to another I am getting the following error:
"Cannot copy a list item into an another list".
Can anybody tell me how i can solve this?
This behavior is currently by design. The reason is that content lists (doc lib, task list, etc.) may contain local list fields. If you had a document in a list with a custom metadata field filled with a value, you would loose that value if you copied the document to another list.
Workaround 1
If you do not need the list/library functionality (custom metadata fields, etc.) than store documents in a simple folder instead of a list. This will let you copy those documents wherever you want - even into a list. In this case you have to take care of setting the allowed child types (most likely File) somewhere on the parent chain (e.g. on the workspace), because you cannot set this value on simple folders.
Workaround 2
Copy files using a temp folder. It is allowed to copy a file from a list to a temp folder, and also copy a file from a folder into a list. I know, this is not very convenient and we are considering changing this behavior to make it more permissive, but this is how currently works.
I'm working on enhancing metadata in our SharePoint online (O365) environment. Since a portion of my user base is used to foldering (explorer style), I've started using default column values to automatically set values on any files added to that specific folder (we have content organized categorically by folder currently). An example is our HR documents library - we have separate folders for recruiting, payroll, personnel files, etc. that automatically categorize files added to that folder with the same categories (recruiting, payroll, personnel, etc.). This supports both "search" and "click" users and makes adoption WAY easier while getting important metadata.
I want to implement this in a larger, more dynamic fashion, so manually setting default column values on each folder is not going to be scalable.
How can I reference the top level folder within the library (or even the current folder) for each newly added file and populate the "category" field for that new file with that folder name? I can do some very basic C# or Java code copy/paste, but bonus points for non-coding solutions =)
This problem can be solved through no coding.You can use the workflow to implement this by SharePoint Designer.
Create different view for different function team, and then use the view filter to show the document.
If you upload a file, use the workflow to set the metadata of the file. There are some known limitations: if you upload multiple files at the same time, the metadata for the file maybe does not work well; or if you upload a folder, the meta will not work for it and the file in the folder may not be set to right metadata.
I was actually able to use MS Flow to accomplish this in a pretty simple and straightforward fashion without managing custom views per team. The concept at a high level was:
(Trigger) When a new document is created in a folder in the library
Get the link of the parent folder of the newly added document
Create a variable (or just code it out in the Flow step) to parse out the name of the parent folder from the parent folder link (should be all text to the right of the last "/")
Set the category field as the variable
I'm sure that you could do the same right in a SharePoint designer workflow, but I prefer flow due to the visual aspect of it and being far easier to troubleshoot.
This suppose to be a simple issue; not to be posted as a question in stack overflow!
Following this article: How to: Create Embedded Resources
I had created a new and fresh Form1.vb to test in Visual Studio 2017 community edition.
Added a big testfile.WAV file as a test resource.
Checked the link type is set to default value: "Linked at compile
time" Default Value.
Clean/Build/Rebuild the application.
Still no matter what I do, the result.exe file is so big and reflect the big testfile.wav file size, and can't at any situation find the wav file as a linked resources in separate file in bin\Debug folder!
Tried to alter almost everything everywhere; yet no success!
What I expect is to have both result.exe and testfile.wav in bin\Debug folder separately linked and not embedded.
Looks very weird to me? is it a bug in VS or in app setting?
Thank you so much
Appreciated any hint
Note: What I was trying to reach is to create a different themes for my application, where users can chose the appearance; and my efforts break in the above scenario. It doesn't make sense that result.exe ends in 10s of MB if it will include resources inside it!
TL;DR: If you want it as a loose file then you need to have it as a loose file. Resources are always embedded in the application.
If you add the resource via Project Properties > Resources then it will always be embedded in your application.
If you want it as a loose file then you shall just import it to your project via Add Existing Item and set the Copy to Output Directory property of the item to Copy Always. Then you reference it by doing for example:
Dim WavPath As String = Path.Combine(Application.StartupPath, "yourfile.wav")
Dim WavFile As Byte() = File.ReadAllBytes(WavPath)
Linked vs Embedded only make a difference at design time. Linked resources are still embedded in your application, but at design time you may edit them and can easily add or remove other resources.
Embedded resources however are embedded in a .resx file even at design time, and to edit such resources you have to export them or change them into a linked resource. Embedded resources are mostly used when you need to share the same resources in multiple projects. The resources are then embedded in the .resx file so you only need to copy that and not every included file.
I have a Component in an installer Project (created with an old Installshield Version).
The Class table entry in the MSI is created correct. But when the installer runs the entry in the registry (LocalServer32) is created with a short 8.3 Name.
What can I do so that the entries in the registry are made with the full 32bit long filename?
The problem behind it:
My component tries to locate localized DLLs with the filename. But when the component is launched with the 8.3 filename the fielname returned by GetModuleFilenameis also in 8.3 format. So when it just appends DEU to the name and changes the extension to DLL to locate the localized DLLs this sometimes fails. And I can not modify this component. (I.e. CompenentName.exe tries to find CompenentNameDEU.dll)
When I register the component manually (ComponentName.exe -register) the entries are made with the full long filename and everything works perfect.
A way around your problem is to use the GetLongPathName() API to convert the path to the long version of the filename.
This should work regardless of whether the argument is a shortened 8.3 path or whether it's already a long path.
Look at the rest of the registry entries that are created. I suspect you'll find something like a LocalServer32 data item (not a key) with apparent garbage in it. If so, what happens is that the 8.3 name is not used to locate the COM server. That "garbage" contains an encoding of ProductCode and Component guid that are used with MSI APIs to locate the target file, invoking repair if necessary.
So if this is what you see, the short answer is "don't use the Class table" because it creates an MSI links to find the target, not a file path.
I have a question whether what i am trying to do is doable, and if the answer is yes how to do it.
I am new to the wix and have been doing some reading on how dynamically to include a folder to an installer and eventually i were able to do a task in nant that uses heat.exe to generate wxs file and latter adding newly generated wxs file to light and candle tasks. This allowed me to add the content of a folder to the msi and subsequently have that folder and its content to be installed.
My problem starts at the point where the folder that i am adding to the msi contains files that has their names already localized (this is a requirement).
When i am adding a file to the directory structure that has its name in Russian for example which is not 1252 codepage i am getting the error:
[exec] ......Templates.wxs(65) : error LGHT0311 : A string was
provided with characters that are not available in the specified
database code page '1252'. Either change these characters to ones that
exist in the database's code page, or update the database's code page
by modifying one of the following attributes: Product/#Codepage,
Module/#Codepage, Patch/#Codepage, PatchCreation/#Codepage, or
WixLocalization/#Codepage.
I tried to set Product/#Codepage to 65001 (UTF-8) however that did not solve the problem.
Eventually what i want to do is to have an ability to add a folder and its content to installer and someone else latter add any number of files that has their names localized into that folder. This way whenever the build runs and subsequent creation of msi happens, msi would contain that folder and its content.
Thank you very much in advance.
This is what WiX.chm says about setting the code page of the MSI database:
You can set this to a valid Windows code page by integer like 1252, or
by web name like Windows-1252. UTF-7 and UTF-8 are not officially
supported because of user interface issues. Unicode is not supported.
As long as you are going to have files named in different languages, that is, File table won't fit into a single Windows code page, you have very little choice. UTF-8 is said to be not officially supported, and this leaves a place for a hope.
If you set the CodePage attribute of the Product element to UTF-8, it will build successfully. And you can install/uninstall the resulting MSI with no problem. I have played a bit with it, and didn't face with any "interface issues" mentioned in that warning above.
Furthermore, I've googled the topic a bit, and found out that InstallShield allows setting the MSI database code page to UTF-8, which is reflected in their docs (search for 'utf-8' on that page). They have more to say about the potential interface issues:
However, some scenarios result in user interface issues. For example,
if an end user specifies the /qb command-line option or uninstalls the
product from Add or Remove Programs, Windows Installer uses very small
fonts to display the user interface text in a UTF-8 database.
They also want to stay on the safe side, hence this setting is false by default (no UTF-8, just ASCII).
So, finally, what would I do in your situation?
if that's a strict requirement to the installation package, use UTF-8 as code page
test all possible scenarios (install / uninstall / repair / upgrade / etc.) on all possible combinations related to localization (English OS, non-English OS, various combinations of current culture and culture UI)
if you face with those ghost "interface issues", show those to your stakeholders, decide whether this is what you can live with and publish known issues if you do
otherwise, recycle this idea and just thank your life for an opportunity to level-up your skills in this area :)
Hope this helps.