Search the Community

Very glad to see that the new tutorials have subtitles for the languages which the Affinity site supports. This will save me time when I explain to my colleagues in photo club of the Volkshochschule Rheinfelden how I develop and edit my photos in Affinity Photo. With regard to the tutorial HDR from one exposure (https://affinity.serif.com/de/tutorials/photo/desktop/video/341759551) I have found some mistake that will wreak much confusion: 00:44 Wir belassen das dabei 00:47 denn wir wir die Ausgangs-Farbkurve anwenden -> denn wenn wir die Ausgangs-Farbkurve anwenden 00:51 werden unsere Werte außerhalb der Grenzen liegen. -> werden die außerhalb der Grenzen liegenden Werte abgeschnitten. One could consider using the subjunctive here, i. e., denn wendeten wir die Ausgangs-Farbkurve an, würden die außerhalb der Grenzen liegenden Werte abgeschnitten. At any rate, as it stands, the text makes no mention of the fate of out-of-bounds values, namely, that they will be clipped. Regarding the translation of to clip as clippen, I have the feeling that one says in German, that highlight details clippen, but not that they geclippt werden (are clipped), i. e., that clippen is intransitive and has no passive voice, even though the past participle, geclippt, can be used adjectivally, e. g. when speaking of geclippte Highlight-Details. That is why I used abgeschnitten, not geclippt. 02:12 und wir können sie kolorieren. I am puzzled about the use of kolorieren. I have not encountered kolorieren as a translation of to tone map. Linguee.de seems to imply that tone mapping is usually translated with das Tone Mapping, and gives many examples where the verb to tone map is rendered as to do or to perform a tone mapping. Actually, though, developing to a 32-bit space means, more generally, that out-of-bounds values are retained and remain available for all the things that one can do to the output of the Develop persona, including but not limited to tone mapping. I suggest, und bleiben für die Verarbeitung nach der Entwicklung der Roh-Datei erhalten -> and remain available for processing after developing the RAW file. This, of course, means that tone mapping, or whatever it is being called in German in Affinity Photo, is one such "thing."

Getting into Publisher lately I noticed that – like everything else – even the designations/names of the font weights (i.e. "Condensed", "Extended" etc.) are being translated as well when using the German language localisation for the app's UI. This may be well meant but for any designer with a bit of typographic experience this is utterly irritating! By years of daily use of any layout or design application we are so used to the "normal" english designations which – after all – have also been applied to the fonts in the font design software used to generate the font files. Accordingly it does make absolutely NO sense to suddenly find a font weight called "Gedrängt" (or other strange, in daily practice completely unusal designations) in the menu, while you're actually looking for the "Condensed" style you're expecting to see listed in the menu. I really, really urge you to change this behaviour of the Affinity Apps by expressively exempting font weight or styles from the diverse translations of the applications UIs. I'd really like to see my fonts and font weights/styles listed exactly as I see them listed on MyFonts, FontShop or wherever I usually choose to purchase them. Apart from this it makes collecting the actual font files used for a document unnecessarily difficult if the the (translated) names/styles in the font menus don't allow for clear and unmistakeable identification of the corresponding (naturally untranslated) font files. So PLEASE leave the font names and styles as they are (english) – regardless of what localisation is used with the apps ! Apart from that do keep up the great work so far and keep evolving!

Affinity Publisher 1.7.0.174 on Windows 7, 64bit (German) can auto-correct standard quotes into typographic quotes, which is very useful and a more-or-less standard feature in all serious writing software. Unfortunately, it appears that it can only correct English quotes ("stuff" into “stuff”). It would be nice if the auto-correction would take into account the currently selected language and use the most-often-used quote characters of that language, e.g. (zoomed for better visibility, would even be better with a serifed font): English: “text” and ‘text’ (as is already done) German: „text“ and ‚text‘ French: « text » and ‹ text › (plus others). This should more or less work flawlessly with the double quotes, but might be undesirable with the single quotes, because here, a closing German single quote (looking like a 6) and a German apostrophe (looking like a 9) cannot be distinguished via the usual algorithm. The same is valid for French (it's easy for English, because there, both apostrophe and closing single quote look the same). My suggestion for an algorithm with which to discern closing quotes and apostrophes would be as follows (as far as I know, no other program does that): If a single quote is entered and the character before it is a space or opening bracket or similar, replace the single quote by an opening single quote (this is already done and should always yield nice results). If a single quote is entered and the character before it is not one of the above, replace the single quote by a closing single quote (this is already done and yields good results, but might be wrong if apostrophes are desired). (this is new) If a 'normal' textual character is entered and the character directly before it is a closing single quote, replace that closing single quote by an apostrophe. This would mean that in case of writing the words it's nice, the single quote would be replaced two times, but at least the end result would be correct... To make it worse, some languages support more than one type of quotes: E.g., since the usual German quotes don't look very nice typographically, most German books use »this type«. Therefore, it would be wonderful if the user could select the auto-correction characters language-dependent manually. One could either include a (rather long and tedious) list of supported languages (as in the screenshot taken from a German text processor, which only supports typical languages used by Germans and is therefore not enough), or offer some edit fields for the user to fill in, as is currently done in PagePlus (which is nice). Andreas Weidner

(I found no other posting to collect all the possible localisation issues in photo, so I start a new one) German: "Cyan", not "Zyan" the color "Cyan" as in the "Selektive Farbkorrektur" or selective color correction is wrongly translated to "Zyan". I checked and it is also in the 1.6 release.

Hi. Is it possible to translate the menu window into Spanish?. Currently in English Float = Flotante Float All = Todas flotantes Dock = Acoplar Dock All = Acoplar todas None = Ninguna

Looks like on the batch processing panel the bounding box isn't sized wide enough here for the German localized text on the switchable radio button group ...

Some property boxes are not localized. See attached file. It's no drama - just a memory hook ;-)