看起来你在调用Google翻译API处理GCS上的PDF文件后，遇到了签名URL无法访问的问题，报了NoSuchKey错误，我来帮你梳理下可能的原因和排查方向：

首先先明确你的场景和问题：

• 你写的Java函数接收两个参数：GCS文件的签名URL、目标语言
• 逻辑是调用翻译服务处理文件，将翻译后的文件存到原路径下，文件名追加类似_translated的后缀，最后返回新的签名URL
• 现在的问题是返回的签名URL无法打开，错误提示指定的对象不存在：No such object: we-aid-translation/3159_Invoice-24BD5880-0009_DE_translations.pdf

可能的问题点及排查步骤： #

1. 翻译后的文件根本没写入预期的GCS路径

先去GCS控制台直接查看we-aid-translation这个存储桶，确认里面是否存在3159_Invoice-24BD5880-0009_DE_translations.pdf这个文件。如果找不到，说明翻译服务并没有成功把文件上传到你预期的位置，自然会报NoSuchKey。

• 检查你构建TranslateDocumentRequest时的输出配置，是不是正确指定了GCS的目标存储桶和文件名？比如GcsDestination的设置是否和你预期的一致？

2. 文件名拼接逻辑有拼写或提取错误

你提到代码里用inputFileName.replaceFirst("[.][^.]+$", "")来提取无后缀的文件名，这里要注意几个点：

• 确认inputFileName是不是单纯的文件名（比如3159_Invoice-24BD5880-0009_DE.pdf），而不是包含了完整的GCS路径？如果包含路径，这个正则可能提取不到正确的文件名。
• 注意到你描述里说的是追加_translated后缀，但错误信息里的文件名是_translations（多了个s），这很可能是拼写错误！比如你代码里拼接的是_translations，但自己以为是_translated，导致生成的签名URL指向的文件和实际翻译生成的文件名不匹配。

3. 签名URL生成时的路径参数错误

生成新签名URL的时候，要确保你使用的GCS对象键（也就是文件路径）和实际翻译后的文件完全一致：

• 检查是否存在大小写错误：GCS的对象键是区分大小写的，比如Invoice和invoice会被当成不同的对象。
• 确认存储桶名称和对象键有没有搞混，比如是不是把对象键写成了存储桶名，或者反过来？
• 有没有多余的斜杠或者缺失的字符？比如路径里的空格、换行（错误信息里的文件名有换行，是不是代码里拼接时引入了换行符？）

4. 翻译服务的输出路径配置和手动拼接不匹配

有些时候，Google翻译服务的translateDocument接口会根据你配置的输出模板自动生成文件名，如果你手动拼接的文件名和服务实际生成的不一致，就会出现这种问题。

• 可以从TranslateDocumentResponse里提取实际的输出文件路径，而不是自己手动拼接。比如查看response里的gcsDestination相关字段，直接用这个路径来生成签名URL，能避免拼接错误。

调试小建议： #

• 在代码里打印出你拼接后的完整GCS对象路径（存储桶名+对象键），然后和GCS控制台里的文件路径对比。
• 打印inputFileName的值，确认文件名提取是否正确，以及最终拼接后的文件名是否和错误信息里的一致。
• 如果翻译服务返回的响应里包含了输出文件的具体路径，优先用这个路径生成签名URL，不要自己手动拼接。

备注：内容来源于stack exchange，提问作者Waqas