URL-based searches of your Google Drive

Just before a recent short holiday, I ran across an article from 2017 which described how to search Google Drive directly from Chrome's address bar. "Interesting," I thought, and with the possibility of integrating such Google Drive searches with IntelliWebSearch or memoQ's integrated web search feature (or similar features in other environments) in mind, I shared the link with a few friends.

Google Drive and its application suite, which includes GoogleDocs (the word processor) and Google Sheets (the spreadsheet application), offer many possibilities for helping in language projects, collaborative and otherwise. I have written extensively about these possibilities with terminology (here, for example, and in a number of related articles). But these earlier investigations involved specific documents and viewing these - or selected portions of them - in a web browser window. Searching a number of files of various types on one's Google Drive ("My Drive") or a subfolder thereof is a little different. Possibly more useful in some circumstances, such as in a group project where multiple participants are contributing to a shared reference folder (though this folder will have to be added to the "My Drive" of each collaborator).

Google's Help for the relevant search function explains:

You can find files in Google Drive, Docs, Sheets, and Slides by searching for:

• File title
• File contents
• Items featured in pictures, PDF files, or other files stored on your Drive

You can only search for files stored in My Drive. Files stored in folders shared with you won't appear in your search unless you add the folders to My Drive.  

You can also sort and filter search results.

It all starts with a basic URL, such as

https://drive.google.com/drive/search?q=SOMETEXT

Execute that in your browser's address bar, replacing the SOMETEXT with your desired search expression, and you'll get a hit list of all files on your Google drive which include that text in the title or contents. In a tool like memoQ Web Search, it is substituted by the placeholder for search text that the application uses (that is {} in the case of memoQ Web Search). With a little experimentation, you'll soon find the additional arguments to search specific file types or folders.

For example, if I want to do a search in the "Other" subfolder on my Google drive, I can discover the URL arguments by starting a manual search and just reading the address bar:

The parameter to use for a specific folder search is "parent", followed by a colon and the coded ID of that folder.

An example of a folder search with a specific text segment is in the screenshot above; this was taken while configuring and testing the search in a memoQ Web Search profile. One document containing the search text "turnip" was found in the folder. To view the document, right-click on it in the hit list and choose Preview.

Search inside the preview of a document found in a Google Drive search with memoQ Web Search

Unfortunately there seems to be a bug in the memoQ Web Search - which now uses Chromium - because double-clicking the document tries to open it in the old search engine based on Internet Explorer, where I was not logged in to Google.

An Internet Explorer window, bizarrely launched by the Chromium-based memoQ Web Search

In fact, you'll have to log in to Google each time you open the memoQ Web Search window (a total nuisance), so it's better to leave it open in the background, even though the current bug in which the web search window is no longer brought to the forefront can make this inconvenient. In other tools this may not be an issue.

The Chromium/IE issue as well as the focus and login hassles with memoQ's web search have been reported to memoQ Support; I look forward to seeing how these are handled. Nonetheless, this Google Drive search seems to have significant potential for individuals and teams to build searchable document collections in the folders of a Google Drive account. Try it in your working environment and share your findings!

No comment... on memoQ "light" resources and their editors

The memoQ working environment includes a number of editing functions and modules, some better developed and more useful than others. Unfortunately, the terms "better" and "more useful" cannot be applied to many of those functions for creating and maintaining resources for auto-translation and many other functions. And, at the present time, integrated facilities for documenting the purpose and function of resources are usually limited to a short description field. The consequence of this can be, in a better case, some confusion, and if you are unlucky you might lose and or accidentally delete resources or apply a version unfit for use.

Auto-translation rule set editor with inadequate space for reading and writing the rules.

The auto-translation rule set editor is a particular headache for me. Scrolling back and forth in a tiny field to read and edit a long match rule (here, in the example of the number-matching auto-translation rules provided with the memoQ installation) is difficult and error-prone.

Even with the dialog-based editors which don't look much like editors (such as the example for QA options configuration below), it's hard to get an overview.

Unless I can compress all the relevant information into the description field for the resource, the only way I am going to get an overview of which functions are enabled is to go through all eight tabs for the QA profile in that dialog. Yuck. And the "why"? Maybe recorded in a notebook buried in the paper pile of my work table if I'm lucky.

There is a better way. And while that way is followed by a number of technically adept colleagues and developers I know, unfortunately it is not usually discussed and taught in workshops and other training venues, nor is it promoted by the software providers for memoQ in any way of which I am aware.

I typically recommend the use of specialized text editors, such as the free text and source code editor Notepad++ for most development, maintenance and documentation tasks involving memoQ light resources. It is available at no cost to everyone and offers simple functions to help you get an overview, edit and document your resources. Only a tiny bit of arcane knowledge is required.

Armed with such a tool, or even with the simple Windows Notepad application, there are a number of useful things that can be done, such as:

Add <!-- comments --> to the text of an MQRES light resource file saved from memoQ

The markers shown in red in the previous line can be added to a line in the file to provide explanatory comments or maintenance instructions. In files with regex content, I often use comments to explain to myself the use of syntax that I will otherwise forget and be unable to understand in a matter of hours or at best weeks.

Example of an auto-translation rule set with comments added

Note that these comments are stripped when resources are imported into memoQ, remaining only in the original external file. Thus, a workflow involving external development and documentation in the resource files, with imports to memoQ for testing and use, is highly desirable. If deficiencies are found in the resource, it should be corrected externally in Notepad++, etc. and re-imported, not fixed in-situ in memoQ, where no information will be present regarding the resource, its purpose and mysterious details.

Comments of this sort night be added to a QA profile, for example, to give a quick overview of the resource and its purpose in more detail than the description field allows (and I often forget to update that description field, because it is in the header of the file, which is usually not of much interest for developing and testing configurations, except to note a version number and a few details). 

Edit the resource more sensibly, using standard text editor features like search and replace

Often I'll decide to add nonbreaking spaces to a date or currency expression (or to the French output numbers in the "French Group" numbers auto-translation rule set provided with memoQ, which unfortunately probably still uses ordinary spaces as separators for thousands, millions, etc.), and this can be totally tedious in the internal editors of memoQ. Such tasks are much simpler in Notepad or Notepad++, for example.

It's also much simpler to find multiple instances of a word or structure that needs amendment or to do just about anything else when you can see all the content in a larger display.

Where resources are in fact simpler to develop inside memoQ, it is still worthwhile to export MQRES files as security. Comments added to these are a form of internal documentation which can avoid confusion and mistakes later when sorted file messes on a hard drive.

Teach and practice resource development and maintenance more effectively

A heavily commented resource file can be thought of as an easily portable "textbook" which includes a functional, importable example of its teaching. And when another person receives a copy of such a file as an example, it will be much easier to understand its structure and purpose and make any necessary changes.

"Faulty" memoQ light resource defaults and how to change them

So often in the decade since I began using memoQ, I've felt an undercurrent of irritation at some of the default settings for certain types of resources, and with the need to switch these resources manually in so many projects. But with so many other pressing matters, I didn't really focus on the problem until a participant in last week's summer school course at Universidade Nova in Lisbon expressed the same irritation with regard to the default QA settings.

QA settings are probably the most familiar irritants to many memoQ users. Some have declared memoQ QA to be "unusable" because of many false positives or a failure to check certain things, and these opinions are usually unfounded and reflect a poor understanding of the available options and how to use them. But even those of us who do know how to use them get caught out by forgetting to change the QA settings to our favorite profiles on many occasions.

No more. If, for example, you want to change the memoQ QA default settings, it is very easy to configure them to match your preferred profile. I started off by cloning my empty QA profile, a template file that I maintain in which no checks at all are enabled. This is the starting point I use for custom QA rule sets in memoQ.

I then edited the renamed file and configured it with the terminology, auto-translation rule and tag settings I prefer in routine cases, leaving many of the usual, irritating memoQ QA defaults disabled. Then I exported the MQRES file as a backup and opened it in a text editor.

There I copied all of the text starting with the XML declaration (skipping the MemoQResource header), and I looked (for example, in the Resource Console, though the Options and Project Settings would do as well) to see where the default resource was located:

Then I went to the file location...

... opened the file, and pasted the copied text of my desired settings into the file:

Default resources (as well as already-imported light resources) do not use headers. Then I saved the new default file and closed it. Then I started memoQ again and make a copy of the Default file for QA settings, and used the editor to examine its contents, which matched those I had pasted into the file for the QA option defaults.

I'm not sure (yet) whether these defaults will be replaced when bugfixed builds or new versions are installed, so I am keeping my exported custom QA configuration as a backup in case I need to do this again. And I will be looking at other light resources which might benefit from this approach.

I had originally considered setting my empty QA profile (with nothing set) as the default until I realized that this could lead to a false impression that nothing of interest was wrong if that default profile is accidentally chosen (or not deselected, rather) for a quality check. Then I realized that the best default to use would, of course, be the settings I use most frequently.

One objection to this procedure raised on social media is that one can set the default for new projects in the memoQ options under "default resources". However, this does nothing for projects which already exist. In these, the change would have to be made project-by-project. And for users who tend to re-use projects for a particular client rather than use the powerful, but somewhat confusing project templates feature, this is a real time-consuming nuisance. Changing the installation-level defaults automatically changes how QA is done in all the exiting projects that use "default" QA options.

iOS 13: interesting options for dictators

Given the deteriorating political situation of many countries in the world today, the title of this post may seem ominous to some; however, the actual situation for those who use Apple's iOS operating system seems to call for some optimism in the months ahead. Among all the myriad feature changes in the upcoming Apple iOS 13 (now in the Public Beta 2 phase), there are a few which may be of particular value to writers and translators who dictate using their iOS devices.

Attention Awareness
This is 2019, and not only is Big Brother watching you, but your iPhone will as well. The rear-facing camera on some models will detect when you look away from the phone – perhaps to tell your dog to get off the couch – and switch off voice control. The scope of application for this feature isn't clear yet, and I have my doubts whether this would be relevant to more ergonomic ways of working with applications like Hey memoQ (which involve Bluetooth headsets or earsets to avoid directionality problems as the head may turn to examine references, etc.), but for some modes of text dictation work, this could prove useful. I have lost track of how often I've been interrupted by people and found my responses transcribed in one way or another, often as an amusing salad of errors when I switch languages.

Automatic language selection in Dictation
The iOS 13 features preview from Apple states, "Dictation automatically detects which language a user is speaking. The language will be chosen from the keyboard languages enabled on the device, up to a maximum of four." Well, well. I wonder how it will handle isolated sentences or paragraphs quoted in another language – or individual foreign words. I'm betting probably not. But I'll have great fun pushing this feature around with three or four spoken languages to find its limits.

Add custom words
This is what I have wanted for years. Custom audio recognition vocabulary – words and phrases – to ensure that unusual or specialist terms are recognized and transcribed correctly. BINGO!

On-device processing
All audio processing will be handled locally (on your iPhone or iPad), ensuring privacy if you believe the NSA and/or the Russians or other parties aren't tapped into your equipment.

Enhancements to voice editing and voice-driven app control
There are a lot of these. Read about them in the Accessibility section of the features description from Apple. My first impression of these possibilities is that editing and correcting text may become much easier on iOS devices, and the attractiveness of the three-stage dictation/alignment/pretranslation workflow may increase for some translators. (An old example of this is in an old YouTube video I prepared years ago for a remote conference presentation, but the procedure works with any speech-to-text options and has the advantage of at least two revision steps.)

It's even more interesting to consider how some of these new features might be harnessed by apps designed to work with translation assistance environments. And if Google responds - as I believe the company is likely to do - with new features for Chrome speech recognition and voice control features in Android and desktop computers, then there could be some very, very interesting things ahead for wordworkers in the next year or two. Vamos ver!