We Keep Coding

Schema for handling duplicate filenames on user import?

I am developing a presentation style app (e.g. Powerpoint, Keynote) in Electron where the user can import their image files into a project folder and I am wondering how to handle the issue of potential file name conflicts.
I don't want to be reinventing wheels: are there schema, design patterns or frameworks for this sort of thing? For example on OSX, iPhoto uses date, time of import plus seemingly random(?) ids to organize imported images.
I will be implementing this is Javascript but am interested primarily in how to approach the problem so language doesn't matter.
iPhoto Library:

There are two approaches I am aware of:
Unique folder names
By placing each file in a folder with a unique name, you can preserve the original file name and avoid any clashes. This method will make things much easier for you if you want to store associated files (e.g. image thumbnails) with the original.
You can generate unique folder names using a UUID, which is a string that is virtually guaranteed not to clash. There are plenty of Node.js libraries to generate a UUID, such as uuid. Or just use any random string and check if the folder already exists to be sure.
Alternatively, as in the example you gave, the folder names could be generated according to date and time, but you have to be sure that you will only add one item at one point in time, or add random folders under the date as in the iPhoto example. The dated folders in iPhoto are probably not necessary when they are also using random-strings as folder names, but they would make it friendly for a user who is manually browsing through the folders, and there may be performance benefits if iPhoto needs a directory listing for a specific date.
You need to store a reference to both the folder name and the file name in order to load the file, but of course this could be one string e.g. "6c84fb90-12c4-11e1-840d-7b25c5ee775a/image.jpg".
Unique file names
Another technique is to rename files to have a unique name whenever there is a clash. This is the approach used by the macOS Finder when you create new folders or duplicate a file. This approach is usually best if the user may interact directly with the files, as they will not have to navigate through folders with meaningless names.
As a simple example, let's say I am adding photos of penguins, and I've already added a photo called penguin.jpg.
Now I add a second photo which also happens to be called penguin.jpg.
Check if penguin.jpg exists. It does, so...
Generate a new name for the file, penguin-2.jpg
Check if penguin-2.jpg exists. It doesn't, so...
Save the new file as penguin-2.jpg
If I add more files also called penguin.jpg, the program needs to keep incrementing the name until I find one which does not exist (e.g. penguin-3.jpg). This should not cause any performance issues unless adding thousands of files with the same name (which seems unlikely).
I found a Node.js module which can handle this approach for you: uniquefilename

Encoding file names in a file system storage

I am creating a simple file system storage in which I name my files using several special characters (e.g.: /, :, ;, *, ?), so subsequently these file names will be converted into unidentifiable expressions once I store my data within the file system.
When I now try to make use of my files within my code my stored data gets "useless" as I am not able to identify it with my intended file names anymore.
Are there some ways or methods to be recommended which I can use to encode my file names before using them as such and decode them back to their original expressions once I need to use them in my code again?
Especially with regard to the deletion of files from my system it would quite helpful to possess the same expressions for my actual file names and the received file names from my storage.
Thanks in advance!

I would use a base64url encoding. The encoding should be supported by librarys in every major language and you can use shell tools too, if you ever want to access the files manually.
But if you have a limited charcter set, you can simply replace the characters by safe ones.

gettext-style keys with i18next, and general workflow

We would like to exchange PO files with translators, and convert these to i18next's native JSON format. This sounds pretty straightforward using the i18next-conv utility.
However, i18next expects more or less special keys; for example the dot has special meaning with regard to i18next namespaces. In contrast, gettext PO files are intended to carry source strings (in the original language) for their message IDs.
We know that message IDs can be arbitrary, and can thus be mapped to i18next keys directly, but we would like to use source strings and use PO files as they were intended for various reasons.
The main reason is that all the translation tools we would like to use, and probably those of all our translators, expect this. Using symbolic keys would make translating a real pain. In any case, we figured from the debates around this that this is mainly a matter of opinion; we kind of made ours, and we would like to put this restriction as a requirement for this question.
Is it really a bad idea to use source strings as i18next keys from a technical standpoint? How hard is it to escape them? Is there anything else than the dot and namespaces that we should care about?
If we determine that we want to keep using symbolic keys, is there an alternative to i18next-conv that can generate i18next JSON translation files from PO files using source strings as message IDs? We understand that we would most likely need to maintain a separate mapping between the symbolic names and the original language strings, and we're prepared to do so.
Moreover, we wonder about the general workflow. How is the original PO file generated? How are the translation files maintained?
If we use source strings as keys in i18next, what are the best tools to extract strings from the codebase? xgettext doesn't seem to support Javascript.
If we use symbolic keys in i18next, how can we best generate the original PO file? Is writing a POT file by hand a good practice?
Again, if we use symbolic keys, how can we easily invalidate translations whenever we update the original language strings? Are there tools for that?
We understand these questions are very basic, but we were a bit surprised at how little information we could find about i18next-gettext integration. The i18next-conv tool exists and works perfectly as advertised, but is it actually useful? Do people actually use it? If so, are our questions relevant?
Finally, are our expectations about the maturity of the system a little too high?

if you like to use source strings as keys just change the
nsseparator = ':::'
keyseparator = '::'
so . and : could be used inside the key without fear.

You could try using https://github.com/cheton/i18next-text. It allows you using i18next translation without having the key as strings, and you do not need to worry about i18n key naming. Furthermore, you can also register the i18n helper with Handlebars.
Following is a simple example:
var i18n = require('i18next');
// extends i18n object to provide a new _() method
i18n._ = require('i18next-text')._;
i18n._('Save your time and work more efficiently.');
Check out the demo on JSFiddle.

What is the javascript filename naming convention?

Should files be named something-with-hyphens.js, camelCased.js, or something else?
I didn't find the answer to this question here.

One possible naming convention is to use something similar to the naming scheme jQuery uses. It's not universally adopted but it is pretty common.
product-name.plugin-ver.sion.filetype.js
where the product-name + plugin pair can also represent a namespace and a module. The version and filetype are usually optional.
filetype can be something relative to how the content of the file is. Often seen are:
min for minified files
custom for custom built or modified files
Examples:
jquery-1.4.2.min.js
jquery.plugin-0.1.js
myapp.invoice.js

I'm not aware of any particular convention for javascript files as they aren't really unique on the web versus css files or html files or any other type of file like that. There are some "safe" things you can do that make it less likely you will accidentally run into a cross platform issue:
Use all lowercase filenames. There are some operating systems that are not case sensitive for filenames and using all lowercase prevents inadvertently using two files that differ only in case that might not work on some operating systems.
Don't use spaces in the filename. While this technically can be made to work there are lots of reasons why spaces in filenames can lead to problems.
A hyphen is OK for a word separator. If you want to use some sort of separator for multiple words instead of a space or camelcase as in various-scripts.js, a hyphen is a safe and useful and commonly used separator.
Think about using version numbers in your filenames. When you want to upgrade your scripts, plan for the effects of browser or CDN caching. The simplest way to use long term caching (for speed and efficiency), but immediate and safe upgrades when you upgrade a JS file is to include a version number in the deployed filename or path (like jQuery does with jquery-1.6.2.js) and then you bump/change that version number whenever you upgrade/change the file. This will guarantee that no page that requests the newer version is ever served the older version from a cache.

There is no official, universal, convention for naming JavaScript files.
There are some various options:
scriptName.js
script-name.js
script_name.js
are all valid naming conventions, however I prefer the jQuery suggested naming convention (for jQuery plugins, although it works for any JS)
jquery.pluginname.js
The beauty to this naming convention is that it explicitly describes the global namespace pollution being added.
foo.js adds window.foo
foo.bar.js adds window.foo.bar
Because I left out versioning: it should come after the full name, preferably separated by a hyphen, with periods between major and minor versions:
foo-1.2.1.js
foo-1.2.2.js
...
foo-2.1.24.js

The question in the link you gave talks about naming of JavaScript variables, not about file naming, so forget about that for the context in which you ask your question.
As to file naming, it is purely a matter of preference and taste. I prefer naming files with hyphens because then I don't have to reach for the shift key, as I do when dealing with camelCase file names; and because I don't have to worry about differences between Windows and Linux file names (Windows file names are case-insensitive, at least through XP).
So the answer, like so many, is "it depends" or "it's up to you."
The one rule you should follow is to be consistent in the convention you choose.

I generally prefer hyphens with lower case, but one thing not yet mentioned is that sometimes it's nice to have the file name exactly match the name of a single module or instantiable function contained within.
For example, I have a revealing module declared with var knockoutUtilityModule = function() {...} within its own file named knockoutUtilityModule.js, although objectively I prefer knockout-utility-module.js.
Similarly, since I'm using a bundling mechanism to combine scripts, I've taken to defining instantiable functions (templated view models etc) each in their own file, C# style, for maintainability. For example, ProductDescriptorViewModel lives on its own inside ProductDescriptorViewModel.js (I use upper case for instantiable functions).

How to do localizable javascript?

I have a web application that uses TONS of javascript, and as usual, there are a lot of textual constants that will be displayed to the user embedded in the code itself.
What do you think is the best way to make this localizable?
I know I need to take those strings off of the code and replace them with constants, which will be defined into some external place.
For the server side, ASP.Net provides some very neat capabilities for dealing with this.
What's the best to do this in Javascript?
The best idea I have is to have a JS file with ALL the string constants of the JS of the site (i'd have different copies of this, for each language), and then on each page, I include this script first, before all the others.
This seems like the most centralized way, that also wastes the least bandwidth.
Are there any other better approaches?
Thanks!

here's how we did it (in ASP.net), pretty much along the lines of what you've mentioned:
1) Created two javascript files: one which defines all javascript functions/DOM manipulations as required by the site, and, second called Messages.js: this defines all the string literals that need to be localized, something like var ALERT_MSG = "Alert message in english".
2) Created different version of the Messages.js, one for each locale that we are supporting and localized the strings. The localized js files were named using messages.locale.js naming convention (for eg. messages.fr-FR.js).
3) Included the js files within the "ScriptManager" and provided the ResourceUICultures for the Messages.js file: this ensures that the correct localized file is embedded in the html output (if you are not using ASP.net you can build this basic functionality by doing some culture sniffing and including the appropriate js file).
4) Voila!

Your approach makes sense. Details:
I'd have the strings for each language in an object.
localized={"cat":"chat","dog":"chien"};
Then in code:
localized["cat"]
The quotations around of the keys and the array notation (rather than the more common object dot notation) are to avoid collisions with JavaScript reserved words.

There is a gettext library but I haven't used it.

Your approach sounds good enough.
If you have lots of strings and you are concerned about the bulkiness of the file you may want to consider a script that creates a single javascript file for each language by concatenating the code javascript and the locale javascript and then applying something like Minify.
You'll waste some CPU cycles on publishing but you'll save some round trips...

There's a library for localizing JavaScript applications: https://github.com/wikimedia/jquery.i18n
The strings are stored in JSON files, as pretty much everybody else suggests, but it has a few more features:
It can do parameter replacement, supports gender (clever he/she handling), number (clever plural handling, including languages that have more than one plural form), and custom grammar rules that some languages need.
The only requirement is jQuery.